(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

Internationa] Bureau 

(43) International Publication Date 
7 August 2003 (07.08.2003) 




PCT 



lllllDlDiligililillllllllllR 

(10) International Publication Number 

WO 03/065256 Al 



(51) International Patent Classification 7 : G06F 17/60 

(21) International Application Number: PCT/GB02/O0463 

(22) International Filing Date: 1 February 2002 (01.02.2002) 

(25) Filing Language: English 

(26) Publication Language English 

(71) Applkant: GLOBAL STRAIGHT THROUGH PRO- 
CESSING ASSOCIATION LTD IGB/GB]; Brown & 
Wood, Princes Court, Princes Street. London EC2R 8AQ 
(GB). 

(72) Inventors: CROSBY, Steven; 2 Wheeler Gate, Westport, 
CT 06880 (US). MERCHANT, Edward, IL; 128 Spring 

j Hill Circle, Wayne, NJ 07470 (US). 

I (74) Agents: MILHENCH, Howard, Leslie et al4 R.G.C. 
Jenkins & Co., 26 Caxton Street, London SW1II ORJ 
(GB). 



(81) Designated States (national): AE, AO, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CI J, 
CZ, DE, DK, DM, DZ, EC, EE, ES, Fl, GB, GD, GE, GH, 
GM, HR, IIU, ID, IL, IN, IS, JP r KE, KG, KP, KR, KZ, LC, 
LK LR, LS, LT. LU, LV, MA, MD, MG. MK. MN. MW, 
MX, MZ, NO, NZ, PL, PT, RO, RU, SD, Sh\ SG, SI, SK, 
SU TJ, TM, TR. TT. TZ, UA, UG, UZ, VN. YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ. TZ, UG, ZM, ZW), 
Eurasian patent (AM, AZ, BY, KG, KZ. MD, RU, TJ, TM). 
European patent (AT, BE, Q I. CY, DE, DK, ES, FI, FR, 
GB, OR, IE, IT, LU, MC, NL, PT, SE, TR), OAPI patent 
(BP. BJ. CF, CG. CI, CM, GA, GN, GQ, GW, ML, MR, 
NE, SN, TD, TG). 

Published: 

- • with international search report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations * appearing at the begin- 
ning of each regular issue of the PCT Gazette 



= (54) Title: POST-TRADE, PRE-SETTLEMENT INFORMATION MATCHING FOR SECURITIES TRANSACTIONS 



If) 
fS 
if) 

© 



50f 



6/P 



6C 



i 



50b 



f60, 



40 



COWiUKKATIONS 
PATHWAY 



, L 



10 




0 



(57) Abstract: Systems and methods for fec^itating settlement of a securities transaction. A communications mechanism is adapted 
to accept incoming electronic messages related to the securities transaction. A processing mechanism, coupled to the commnni ca- 
tions mechanism, determines compatibility between any two or more incoming electronic messages. The processing mechanism 
transmits an indication message over the communications mechanism that specifies at least one on (i) compatibility between any 
two or more incoming electronic messages; and (ri) incompatibility between any two or more incoming electronic messages. 
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POST-TRADE, PRE-SETTLEMENT INFORMATION 
MATCHING FOR SECURITIES TRANSACTIONS 



BACKGROUND OF THE INVENTION 

L Field of the Invention: 

This invention relates generally to financial data processing and, more 
10 particularly, to systems and methods for facilitating settlement of securities 
transactions. 

2. Background Art: 

Securities transactions which transcend national boundaries are an 
15 important and increasing component of worldwide finance. Securities issuers, 
custodians, fiduciaries, buyers, sellers and their representatives, and others 
involved in any particular securities transaction can be located virtually 
anywhere. 

International, cross-border securities trades fail and are not completed 
20 (*.e., do not "settle") far more frequently than trades taking place within a given 
country — and far more often than is desirable to satisfy financial assurance and 
liquidity objectives. Causes of cross-border trade failure are varied, and 
include incompatible views of the parties as to bargain specifics, as well as 
incompatible assumptions and practices regarding settlement mechanics and 
25 timing. Beyond impeding investment liquidity, presently-utilized settlement 
procedures are burdensome and case-dependent, significantly adding to the 
expense and complexity of completing a trade. 

International securities transactions typically involve institutional 
principals (mutual funds, banks, pension fluids as representative) rather than 
30 retail (individual) participants. An agent, such as a Broker/Dealer (B/D) and/or 
an Investment Manager (IM), acts for the ultimate buying and selling entities. 
Securities holdings are most often identified as a book entry in the computer 
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records of a custodian which cither itself, or via a farther custodian, holds the 
underlying securities in its own or a nominee's name. Settlement of an 
international security transaction typically requires "delivery" via appropriate 
book entry adjustments and physical delivery of the security involving at least 
5 one and typically often more than one Global Custodian (GQ or Sub- 
Custodian. 

In some instances, cross-border trades may not involve an exchange 
(e.g., the New York Stock Exchange, the London Stock Exchange, the Paris 
Bourse), whereupon the accompanying exchange-mandated settlement 
10 procedures and member firm settlement assurances are no longer applicable* 
Cross-border trades which do not utilize an exchange are essentially bargains 
directly or indirectly negotiated between an IM (Investment Manager), B/D 
(Broker/Dealer), or the like, where each party to the trade issues the respective 
confirmatory notices and settlement instructions. 

15 In die United States, two centralized security settlement forums are the 

Depository Trust Clearing Corporation (DTCC) and the Government Securities 
Clearing Corporation (GSCC). Specialized clearing agencies exist for 
international securities as, for example, the International Securities Clearing 
Corporation (ISCC). The ISCC is a US-based international clearing agency 

20 registered with the Securities and Exchange Commission (SEC) to provide 
clearance, settlement, and information services to participants trading in 
overseas markets. 

Cross-border securities transactions typically involve multiple tiers of 
intermediary parties, and many investors may be unaware of the existence of 

25 some or all of these intermediaries. Managing the inherent risks of a cross- 
border securities transaction becomes increasingly difficult as the number of 
tiers increases. As the security instrument is transferred from one 
intermediary to another, each intermediary in the chain effects the transfer in 
the form of a book-keeping entry. Typically, the investor does not receive any 

30 piece of paper evidencing ownership in such a security, and must rely upon a 
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series of bookkeeping records to establish his interest in the security. 

As noted above, much can (and too often does) go wrong during the post 
trade, pre-settlement phase of a securities transaction. Misunderstandings 
related to the terms of the bargain are overlooked (at least initially) in crossed 
5 messages. Parties can have different expectations as to applicable costs, taxes, 
risk apportionment, and the priority and sequence of performance. "Delivery" 
between GC's (Global Custodians) may not occur (or not be achievable in the 
requisite timing) for lack of needed information about the transaction and/or a 
lack of compatibility between the information exchanged between or among 

10 the parties. 

As a consequence of the foregoing factors the costs and risks of 
successfully completing cross-border securities transactions is increased. Even 
if the deal is not successfully completed, the parties are typically burdened with 
various transactional expenses (e.g., repair costs and fail financing). Moreover, 

IS present cross-border trading is not readily amenable to next day settlement 
("T+r), which is the desideratum of all capital markets so as to promote 
liquidity and to reduce risk. 
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SUMMARY OF THE INVENTION: 

One object of the invention is to accelerate the flow of information 
between parties participating in a cross-border securities transaction so as to 
decrease the length of a trade settlement cycle to as short as possible, 
5 preferably no greater than the next business day after trade (T+ 1 ). 

A further object of the invention is to reduce cross-border trade failures 
by providing accurate, "just-in-time" infoimation to all parties participating in 
a cross-border securities transaction. 

Another object of the invention is to facilitate cross-border trades by 
10 providing the parties with the relevant parameters of the transaction, and/or 
information about these parameters, and providing data about these parameters 
as the data become available. 

Yet another object of the invention is to provide a system for 
implementing, contemporaneously, a plurality of cross-border transactions and 
15 determining which incoming infoimation pertains to which transaction. 

In summary, a timely, efficient, cross-border securities transaction is 
facilitated by using a communications mechanism and a processing mechanism 
to assess the compatibility of incoming information related to a securities 
transaction, and to provide one or more notification messages indicative of 
20 information compatibility. More specifically, the communications mechanism 
receives incoming electronic messages setting forth one or more parameter 
values related to a securities transaction. These messages may be received in 
the form of Notices of Execution (NOE's) and/or Block Order Notifications 
(BON's). Incoming messages may also specify settlement instructions and/or 
25 settlement details. Messages are received from a plurality of parties to the 

transaction, including an Investment Manager (IM), a Broker/Dealer (B/D), and 
one or more global custodians (GC's). A processing mechanism, coupled to 
the communications mechanism, first determines which messages of a plurality 
of incoming messages pertains to a given securities transaction. After 
30 identifying two or more messages that pertain to a given securities transaction, 
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the processing mechanism tests for matches between one or more parameter 
values of these two or more messages. The processing mechanism transmits a 
message over the communications mechanism specifying at least one of: (i) 
the existence of matches between one or more parameter values of any two or 
5 more incoming electronic messages; and (ii) the non-existence of matches 
between one or more parameter values of any two or more incoming electronic 
messages. 

According 1o one preferred embodiment of the invention, received 
incoming messages specify any of the following exemplary parameters: (1) a 
10 total quantity and value allocation for the securities transaction; (2) a block 
trade amount for the securities transaction; (3) net proceeds expected by that 
party from the securities transaction; (4) maximum acceptable deviation from 
the net proceeds of the securities transaction that a party will accept; and 
(5) settlement location and/or venue. However, the maximum acceptable 

15 deviation need not be received in the form of an incoming message, and could 
be specified in the form of a profile that is pre-stored in electronic memory. 
The parameters may include one or more mandatory parameters and/or one or 
more tolerance-based parameters. If the securities transaction is to settle, the 
mandatory parameters of all messages pertaining to a given securities 

20 transaction should match identically. However, the tolerance-based 

parameters of all messages pertaining to a given securities transaction need 
only match within a prespecified tolerance m order to permit settlement of the 
securities transaction. Each of respective tolerance-based parameters may be 
assigned a corresponding prespecified acceptable tolerance limit The 

25 incoming messages may include one or more NOE (Notice of Execution) 
messages received from one or more Broker/Dealers (B/D's), and/or one or 
more BON (Block Order Notification) messages received from one or more 
Investment Managers (IM*s). 

At a plurality of times during the post-trade, pre-settlement phase of a 

30 securities transaction, the processing mechanism determines whether two or 
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more received messages pertain to a given securities transaction and, if so, the 
processing mechanism subjects this data to the above-described matching 
process. The processing mechanism may optionally be equipped with a 
translation mechanism by which a first security identification code specified 
5 according to a first security numbering agency is translated into a second 
security identification code for the same security, as specified according to a 
second security numbering agency. If the processing mechanism determines 
that all mandatory parameters for a given securities transaction match exactly, 
and that all tolerance-based parameters are within the corresponding 
10 prespecified acceptable tolerance limit, the transaction is considered to be 

matched. Once the transaction is matched, the processing mechanism forwards 
the transaction to the local market for settlement, and/or forwards the 
transaction to the B/D or GC for subsequent forwarding to the local market. 
The processing mechanism sends a message to all parties to the transaction 
15 notifying them of the final terms of the bargain. 

The matching process is adapted to determine compatibility between 
two or more incoming messages. If these incoming messages are compatible, 
a securities transaction may be consummated, whereas if they are incompatible, 
a securities transaction may not be consummated. The notion of compatibility 
20 is dependent upon the parameter in question. Some messages include 
parameters which must exactly match corresponding parameters in other 
messages pertaining to the same transaction. For example, the identity of the 
security to be traded must match exactly; otherwise the transaction will not be 
consummated. However, other messages include parameters which need only 
25 fall within a specified tolerance of corresponding parameters in other messages, 
so as to enable consummation of the transaction. For example, a first message 
may indicate that net proceeds are SI 0,000, whereas a second message may 
indicate that net proceeds are $12,000. However, if the specified tolerance is 
$5,000, the messages are compatible, and the transaction may be consummated. 
30 By way of further variation, a first message may indicate that the transaction 
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must be settled in Hamburg, whereas a second message may indicate that the 
transaction could be settled in Cannes, Hamburg, Cairo, or New Delhi. These 
messages are compatible, because the transaction could be consummated in 
Hamburg. 

5 Pursuant to a further embodiment of the invention, a "just-in-thne" data 

enrichment process is utilized wherein the processing mechanism receives 
settlement details from one or more parties to the transaction at the time that 
these details are needed for matching purposes. In contrast to existing 
processes that rely on standing, preloaded instruction databases, the "just-in- 

10 time" data enrichment process receives current and specific settlement details 
from the GC and the B/D. The "just-in-time M process obtains data from the 
source (the GC and/or the B/D), when this information is needed, so as to 
ensure that accurate, up-to-date, and relevant settlement details are exchanged 
between the GC and the BD. In this manner, the probability that a given 

15 securities transaction will be settled is greatly enhanced. 

BRIEF DESCRIPTION OF THE DRAWINGS: 

FIG. 1 is a hardware block diagram showing an illustrative operational 
environment for the present invention. 
20 FIGs. 2A-2F together comprise a flowchart setting forth an operational 

sequence performed by a preferred embodiment of the invention. 

FIG. 3 is a table setting forth a list of abbreviations and/or acronyms 
which are used throughout the specification. 

FIGs. 4A-4L are an illustrative data structure diagram that describes the 
25 informational content of messages received by the TFM processor of FIG. 1 . 

FIGs. 5A and 5B together comprise a data structure diagram setting 
forth data fields that are used by die TFM for matching purposes 

FIG. 6 is an information flow diagram for a Fund-to-Fund trade, 
FIG. 7. is an information flow diagram for a first illustrative Allocations 
30 Matching Process. 
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FIG. 8 is an information flow diagram for a second illustrative 
Allocations Matching Process. 

FIG. 9 is an information flow diagram showing illustrative message 
transfers for the Allocations Matching Process. 
5 FIGs. 10A-10F together comprise a data structure diagram setting forth 

information provided by the IM to the TFM processor as part of an Allocation 
Message. 

FIG. 11 is a data structure diagram setting forth input and the output 
messages utilized during the Allocations Matching Process. 
10 FIG. 12 is an information flow diagram illustrating "step out" trades 

from file perspective of a "stepping-in" B/D. 

FIG. 13 is a diagram illustrating the flow of information during the 
Allocations Matching Process. 

FIG. 14 is a chart that provides a comparison between an Allocations 
15 Matching Process where the TFM processor has received all required 
information and an Allocations Matching Process where some information is 
incomplete. 

FIG. 15 is an information flow diagram depicting the Allocations 
Matching Process for fund-to-fund trades. 
20 FIGs. 16A-16E together comprise a data structure diagram showing 

illustrative data fields utilized by the TFM processor during a Net Proceeds 
Matching Process. 

FIG. 1 7 is a Prevailing User Tolerance Decision Table used by the TFM 
processor to determine the type of tolerance to be applied so as to match Net 
25 Proceeds within a user-specified tolerance. 

FIG. 18 is a Prevailing Amount Decision Table used by the TFM 
processor to determine the prevailing amount of the trade and the match status 
for various user tolerance match results. 

FIG. 19 is a flowchart setting forth an operational sequence for 
30 implementing the Net Proceeds Matching Process. 
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FIGs. 20-39 are tables setting forth various illustrative results for the Net 
Proceeds matching process of FIG. 19. 

FIG. 40 is a diagram illustrating information flow for a Settlement 
Channel Compatibility Determination Process. 
5 FIGs. 41 A-41E together comprise a data structure diagram setting forth 

various illustrative data fields used to implement the Settlement Channel 
Compatibility Determination Process. 

FIGs. 42A-42E together comprise a data structure diagram setting forth 
various illustrative data fields used to implement a Foreign Exchange (Forex) 
10 Settlement Process. 

FIGs. 43 and 44 illustrate information flow for a Trade Cancellation 
Process. 

FIGs. 45 and 46 illustrate information flow for a Trade Cancellation 
Process where a received NOE or BON message contains an erroneous value. 
15 FIGs. 47 and 48 illustrate information flow for a Trade Details 

Replacement Process wherein one or more new trade parameter values are 
substituted in place of previously submitted parameter values. 

FIG. 49 is a Currency Code data structure for storing currency-related 
information. 

20 FIG. 50 is a Country Code data structure for storing information related 

to a proposed settlement location. 

FIG. 51 is an Instrument Type data structure for maintaining numbering 
agency codes for securities according to instrument type and country of issue. 
FIG. 52 is a Settlement Location data structure for storing details related 
25 to each of a plurality of potential settlement locations. 

FIG. 53 is a Settlement Bridges data structure for storing information 
related to the existence of "bridges" (preexisting settlement protocol 
arrangements) between two or more. potential settlement locations. 

FIG. 54 is a B1C (Bank Identifier Code) data structure for storing 
30 information related to one or more financial institutions. 
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FIG. 55 is a Roles Profile Table describing the functions to be 
performed by each of a plurality of entities such as B/Ds, IMs, and GCs. 

FIG. 56 sets forth an illustrative data structure for a Participant 
Identification Table. 

5 FIG. 57. sets forth an illustrative data structure for a Participant Address 

Table. 

FIG. 58 sets forth an illustrative data structure for a Participant Roles 

Table. 

FIG. 59 sets forth an illustrative data structure for a Participant Access 
1 0 Module Identification Table. 

FIG. 60 is an information flow diagram illustrating the relationship 
between Participants, BICs, Participant Access Modules, the TFM processor 
and the Access Concentrators. 

FIG. 61 is a Transaction Notification Table that stores details 
1 5 maintained by the participant 

FIGs. 62 and 63 are Substitution Profile Tables that store the 
identification of a substitute who will be submitting transaction parameters. 

FIG. 64 is an IM Client Profile Table that illustrates the profiles 
maintained by the IM for its Clients. 
10 FIG. 65 comprises an Accounting Agent Profile 

Table that illustrates the profiles maintained by the Accounting Agent for its 
Clients. 

FIG. 66 is a Matching Tolerance Table that illustrates matching 
tolerance at a Block Gross Amount level. 
5 FIG, 67 sets forth the data structure of a Trade Statistics Table. 

FIG. 68 sets forth the data structure of a Message Statistics Table. 
FIG. 69 sets forth the data structure of a Matching Efficiency Table. 
FIG. 70 sets forth the data structure of a Geographical Characteristics of 
Usage Table. 
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FIG. 71 sets forth the data structure of an Instrument Type Table. 
FIG. 72 sets forth the data structure of a Type of Service Table. 
FIG. 73 sets forth the data structure of a Standards Compliance Table. 
FIG, 74 sets forth the data structure of a Reference Number Table. 
5 FIG. 75 sets forth a data structure by which any of a plurality of 

Message States may be specified in conjunction with the TFM processor. 

FIG. 76 sets forth the data structure of Output Messages as utilized in 
conjunction with the TFM processor. 
10 FIG -77 sets forth . the data structure of a Message Types 

Table. 

FIGs.78, 78A and B set forth the data structure for a 
Block Trade States Table* 

FIGs. 79 A- 79T together comprise a data structure diagram setting forth 
15 various data fields that are utilized by the TFM processor of FIG. 1 . 

FIGs. 80A-80G together comprise a data structure diagram that 
describes input message field elements. 

FIGs. 81A-81I and 82A-82C are data structure diagrams that group field 
elements by input messages. 
20 FIGs. 83A and 83B together comprise a Block Trade Details data structure 

diagram. 

FIG. 84 is a data structure diagram for output messages. 
FIG. 85 is a data structure diagram showing input messages for allocat 

ons. 

25 FIGs. 86A and B together comprise a data structure diagram showing 

output messages for the above-described allocations process. 

FIG. 87 is a data structure diagram showing input messages for the 
above-described Net Proceeds process, 

FIGs. 88A and B together comprise a data structure diagram showing 
30 output messages for the Net Proceeds process. 
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FIG. 89 is a data structure diagram showing output messages related to 
Accounting Details. 

FIG. 90 is a data structure diagram showing input messages involving 
Settlement Details. 

FIGs* 9 1 A and 9 1 B together comprise a data structure diagram showing 

output messages involving Settlement Details. 

FIG. 92 is an information flow diagram for a Fund-to-Fund Trade. 

FIG* 93 is an information flow diagram for Sell-Side and Buy-Side 
Allocations and Notifications. 



12 



WO 03/065256 



PCT/GB02/00463 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Post-trade, pre-settlement information matching for a securities 
transaction is facilitated by providing multilateral communications between 
parties during the post-trade, pre-settlement phase of the transaction. 
Typically, the parties include an Investment Manager (IM), a Broker/Dealer 
(B/D), and one or more Global Custodian(s) (GCs). Although these terms are 
well-understood by those skilled in the art of electronically-facilitated 
securities transactions, they are briefly defined herein for the convenience of 
the reader. GCs are entities which hold the physical certificate^) evidencing 
ownership of a security for the benefit of third parties; for purposes of this 
invention, a GC holds the security of the sellers) and, after the transaction is 
consummated, the buyer(s) may have a different custodian to which the 
physical security is transferred. IM's are charged with the responsibility of 
managing an investment portfolio which may include domestically-issued, as 
well as foreign-issued, security instruments. A B/D acts as an interface or 
liaison between entities that wish to buy and/or sell securities instruments. 
Depending upon the particular parties on a side of a given securities 
transaction, any party could be conceptualized as a "seller" of a securities 
instrument, with any one or more of the remaining "non-selling" parties 
functioning as a "buyer" of the securities instrument. While the present system 
can be used to match trading information for anything from stocks to stock 
cars, as used herein, the term ''securities'* includes any type of intangible asset, 
such as stocks, bonds, options, derivatives of any kind, dematerialized issues, 
and the like. 

In the environment of a typical exchange, such as the New Yoric Stock 
Exchange, NASDAQ, the London Stock Exchange, or the Paris Bourse, 
transactions are typically handled between B/Ds or specialists. For example, 
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an institutional investors IM at a brokerage desiring to purchase 10,000 shares 
of XYZ Company places an order for these shares. The order is received by a 
B/D who then finds another B/D who wishes to sell essentially the same 
quantity of shares* The two B/Ds then consummate the transaction. If there is 
a nriscominumcation between the B/Ds as to price or quantity (for example), 
the buyer and seller are each insulated from this problem by the rules of the 
exchange; e.g., if the buyer only wanted to purchase 1,000 shares and the * 
buying broker, as in this case, accidentally purchased 10,000, the broker (or the 
brokerage house) would be responsible for the remaining 9,000 shares. These 
safeguards axe often lacking in cross-border transactions. 

For the sake of simplicity, assume that two B/Ds are conducting a given 
securities transaction by representing, respectively, a buyer (B/broker) and a 
seller (S/broker). B/broker and S/broker communicate their desired 
transactions to each other using conventional communication techniques such 
as telephony, mail (including courier-delivered and facsimile-transmitted), 
electronic mail, electronic direct file transfer, and/or other means. Eventually, 
they will agree upon the parameters of the transaction. Typical parameter 
values for a securities transaction, and variable names for these parameters 
used herein, are: the identity of the security (SEID); the number of shares 
(SHRNO); and the share price (SHRS). In addition to these, because the 
present invention contemplates transactions across borders, additional variables 
may include transfer, excise, or other taxes the seller's (and/or buyer's) nation 
may impose on the transfer of a security (TRTXS). An additional optional 
parameter may specify variations in share price. Because S/broker and 
B/broker are in different countries, they can decide, during the course of 
negotiations, on the currency B/broker must deliver or tender (BTENDCUR); 
the seller can also specify a particular currency (STENDCUR). The currency 
requested by the seller may not be the currency of the seller's domicile, 
although the security typically will be quoted in the currency of the seller's 
domicile; for example, many financial markets use United States dollars 
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because it is typically usee as a standard currency value throughout the world. 
Thus, the buyer's currency type (BCUR), the currency in which the security is 
quoted (SECCUR), and the exchange rates between (i) the buyer's currency and 
that tendered (XBCUR) and (n) the security currency and that tendered 
5 (XSECCUR) may all have to be specified so that the transaction intended is 
well-defined and understandable to all involved. Of course, the system must 
also identify B/broker (BBRID) and S/broker (SBRID) to track each of the 
foregoing parameters as defined or offered by each party. Clearly, other and/or 
additional parameters can be specified as well; for example, an alternative 
3 settlement forum. 

In addition to items such as alternative settlement forums, currency and 
exchange rates, other issues may arise in cross-border securities transactions. 
Differences in exchange rates, expectations as to tax rates, transfer fees, and 
other fectors may likely render an exact meeting of price and quantity 
> impossible. Accordingly, in a preferred embodiment the parties specify 
respective tolerance limits for one or more corresponding tolerance-based 
parameters within which a matching parameter from the other will be accepted. 
As another example, a party may wish to buy or sell a large block of securities 
for which it may be difficult and/or time-consuming to secure counterparties to 
the transaction. Accordingly, the transaction may have to be divided into a 
number of separate transactions; for example, a holder of 1,000,000 shares may 
have to sell ten blocks of 100,000 shares each because there is no ready buyer 
for all of the seller's shares. 

In practice, this invention is a post-transaction, pre-settlement system 
that facilitates die information exchange to reach the agreement necessary to 
settle the transaction. Assume a buyer in the US desired to purchase 1 000 
shares of XYZ Co. traded in India; based on available information, the buyer is 
willing to purchase the shares at US$ 10.00 each. B/broker makes contact with 
and communicates (by voice, facsimile, and the like) this information to 
S/broker. Assume that S/broker agrees to these terms. The transaction is now 
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specified, and the two brokers preferably (hopefully) will communicate at least 
these details of the trade to each other so that they have confirmation of the 
agreement. Now, in the post-trade, pre-settlernent phase, each of the brokers 
communicates to the present system the parameter values mentioned above; 
5 e.g., SHRNO, SHRS, BBRID, SBRID, TENDCUR, and the like. One or more 
additional optional parameters may include, or take into consideration, 
variations in share price. Each or all of these parameters can be received by the 
system in the form of a Notice of Execution (NOE) message initiated by the 
buyer and/or the seller. Once the system receives an NOE, it identifies the 
10 particular transaction (such as by assigning a unique identifier). The system 
receives further parameter values, for example, from further NOE messages 
sent by B/Ds, and from BON (Block Order Notification) messages sent by IMs. 
Preferably, an identifier uniquely identifying a given securities transaction is 
communicated to the B/Ds and IMs so that future communications, such as the 
15 transmission of values for other parameters, can be accurately mapped to the 
information already stored in the system about the subject trade. 

Further to the tolerance-based parameters mentioned above, each of the 
parties (i.e., B/Ds and/or IMs) can specify their own acceptable corresponding 
tolerance limits for certain parameters. For example, the buyer may be willing 
20 to purchase a given number of shares at US$ 9.90 to US$ 10. 10; the seller may 
be willing to sell the given number of shares at a price not less than equivalent 
to US$ 9.95. The present system accepts each of the values transmitted and 
stores them to determine whether commensurate variables have been 
consistently specified by each B/D (and/or IM) and, if tolerances are identified 
15 for the total net proceeds and/or receipts of the deal, whether the values fall 
within the specified tolerances. Note that the concept of tolerances could 
arise, for example, in connection with monetary values, such as die total net 
proceeds due and/or received for a given securities transaction. 

Because B/broker in the present example resides in the US, die system 
10 can be programmed to enter a default value for BTENDCUR of US dollars, and 
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Rupees for STENDCURl If S/broker specifies STENDCUR as US dollars and 
B/broker does not specify this parameter, the system then indicates to both 
brokers that the values they have indicated for TENDCUR are compatible 
between them, namely US dollars. When a tolerance is specified, the system 
5 will indicate to the brokers that the SHRNO and SHR$ are compatibly 
specified if, at least* the values specified by one fall within the other's 
tolerance. Here, SHR$ will be communicated to the brokers by the system as 
having a value of US$ 9.95 and SHRNO as having a value of 1050. The B/Ds 
(i.e., B/broker and S/broker) need not communicate all of the parameters to the 

10 system at once, but the system will store and track each of the brokers* 
communications as they are received until the information sufficient for 
settlement has been compatibly specified in the system. Preferably the system 
will update its communication to both brokers each time a new parameter or 
value is received by the system. Certain parameters, such as an expected return 

15 or payment, can be calculated by the system; such a calculation of expected 
return or payment can include taxes and fees. 

Once all of the parameters have been specified in a compatible manner, 
the transaction is completed and agreed to by the parties. From a practical 
point, thereafter, the physical certificate underlying the security, or some other 

20 indicia of ownership, must be transferred to the buyer. Typically, an investor 
does not possess the certificate; it is held by a custodian (GQ for the beneficial 
holder, the brokerage. The brokerage where the broker trades has a book entry 
identifying the client, the number of shares owned, and the custodian holding 
the certificates for those shares. After a transaction is completed by this 

25 invention, the certificates should be transferred to the buyer. . 

In practice, the certificate is transferred from one GC to another, 
assuming the buyer's and seller's brokerages use different GCs. GCs may be 
affiliated with one or more settlement forums, such as Cedel, Euroclear, the 
ISCC, or another clearing organization. Certain settlement forums have 

30 agreements with other settlement forums (these agreements are typically 



17 



WO 03/065256 PCT/GB02/00463 

referred to as links or bridges) to facilitate the settlement process after a trade. 
For example, there is a link between a settlement forum known as the Canadian 
Depository for Securities, Limited (CDS) and US-based DTC (Depository 
Trust Company). This link, operational for US and certain Canadian issues, 
5 provides CDS with full access to US clearance and settlement, including 
custody services. US-based ISCC (International Securities Clearing 
Corporation) has a link with the London Stock Exchange (LSE) whereby 
automated checking comparisons, clearance and settlement services are 
provided for UK equities, and safe custody of securities is provided through the 
10 Citibank Corporation. The Japanese Securities Clearing Corporation has an 
ISCC-sponsored omnibus account at the DTC (Depository Trust Company) for 
receipt and delivery of US equity issues listed on the Tokyo and Osaka Stock 
Exchanges. 

A link between ISSC and Cedel Bank of Luxembourg provides for the 
15 settlement of various eligible securities, including PORTAL 144A issues, with 
multi-Surrency^apabilities among Cedel bank participants, other ISCC 
participants, as well as participants or members of any other national clearing 
and/or depository system having a link with Cedel Bank such as, for example, 
Euroclear. The Stock Exchange of Singapore has an omnibus account at the 
20 DTC for the receipt and delivery of US NASDAQ issues quoted in the Stock 
Exchange of Singapore's (SES's) Foreign Equities Market/SESDAQ system on 
behalf of SES. 

Euroclear and ISCC are linked such that ISCC members have input 
capabilities for Euroclear instructions and cancellations. ISCC accepts 

25 instructions from users, reformats the instructions, and then submits them to 
Euroclear. Finally, a link between ISCC and SD INDEVAL of Mexico 
provides for the automated communication of instructions to INDEVAL's 
computer mainframe. This link also provides for clearance and settlement of 
transactions with Mexican equities, in Mexican Pesos or US Dollars, 

30 Settlement confirmations and end-of-day statements are also provided, as well 
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as custody services for Mexican equities, collection of dividends, execution of 
rights offerings, and proxy voting. 

According to one preferred embodiment of the invention, infoimation 
pertaining to any of the aforementioned links is stored (e.g., in a look-up table, 
5 database, and/or data store) within a processing mechanism. Illustratively, this 
processing mechanism is provided in the form of a TFM (Transaction Flow 
Manager) processor, shown in FIG. 1 as reference numeral 10, to be described 
in greater detail hereinafter. After the present system notifies the B/Ds that the 
transaction has been fully specified and completed, the system references the 
io stored custodian information and notifies all of the custodians about the details 
of the transaction so that the certificates can be transferred. The look-up table 
facilitates this communication by notifying GCs having agreements regarding 
these transfers. In a preferred embodiment, S/broker and/or B/broker also 
specify to the system a local market settlement time by which the settlement 
15 (transfer of assets) must occur. This can be implemented by requiring the 
seller's GC to notify the system (or the B/Ds) that the certificates have been 
transferred before the period specified, and if the system does not receive such 
a notification, then the system notifies the B/Ds and the GCs that the agreed 
upon period for settlement has passed and the transaction has failed to settle. 
20 Of course, the B/Ds (on behatf of the parties) still have an agreement and can 
consult their respective beneficiaries to inquire whether settlement should still 
be attempted in spite of the lapse of time. 

The present system is also applicable to "electronic" or "dematerialized" 
securities. These are securities that are only issued in electronic form, and do 
15 not have any other physical indicia (such as a stock certificate) specifying the 
intangible property. Additionally, it may be the case that the security is 
identified with a certificate in the buyer's country but is a dematerialized 
security in the seller's country. In such a case, the present system provides 
instructions to the entity charged with keeping track of the dematerialized 
=0 security, so that the respective interests of the buyer and the seller are 
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accounted for. 

The invention will now be described with reference to the figures. 
Fig. 1 is an illustrative view of the post-transaction, pre-settlement system 
according to the present invention. The system includes a transaction flow 
manager (TFM) processor 10 illustratively implemented using a processing 
mechanism 12 coupled to storage 14. It is to be understood that TFM 
processor 10 may be implemented using a mainframe computer, a personal 
computer (PC), a computer network, or any other type of centralized and/or 
distributed processing system. Storage 14 may be non-volatile, such as, for 
example, a data storage drive, and/or it may be implemented using random- 
access memory (RAM), read-only memory (ROM), and/or core memory. 
Storage 14 preferably may be arranged to store messages from the brokers in a 
message database (DB) 18, and may also be arranged to provide additional 
storage areas for participant profiles 21 {e.g., B/Ds) as well as look-up 
tables 23. Messages (such as an NOE message and/or a BON message) are 
received by the system, and transmitted from the system to the participants, via 
a communications pathway 40. Communications pathway 40 may represent 
any technique for conveying information from one place to another, including, 
for example, wireless communications, wired communications, and/or fiber 
optic links, to name a few. The information may be conveyed using any of a 
wide variety of transmission protocols, including digital and/or analog data 
signals (which could, but need not, be encrypted or otherwise securely 
transmitted), voice (which may also be encrypted), mail (including postal, 
facsimile, and electronic correspondence, the latter two of which can also be 
encrypted for security). Broker/Dealers (B/Ds) 50, through 50* communicate 
with the system via the communications pathway 40, as do Global Custodians 
(GCs) 70, through 70* and Investment Managers (IMs) 60| through 60 n , The 
typical securities transaction includes one IM, one B/D, and at least one GC 
The communications pathway 40 may include one or more dedicated wired 
and/or wireless communication links between the present system and the B/Ds 
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and/or GCs, It may also include a network by which B/Ds, GCs, and/or IMs 
can interface with the system. Such a network can have local areas a 
LAN) and/or span a wider area (e.g., a WAN, optionally with satellite 
communication and/or radio frequency communication). Another preferred 
5 network is the Internet, whexe secure communication can be conducted using 
secure hypertext transfer protocol (Le.> via a private network). 

Refer now to FIGs, 2 A, 2B, and 2C which together comprise a flowchart 
setting forth an operational sequence perfoimed according to a preferred 
embodiment of the invention. The overall operational sequence describes the 

10 manner in which the system of FIG. 1 provides multilateral communications 
between a Broker/Dealer (B/D) 50 h an Investment Manager (IMs) 60f, and one 
or more Global Custodians (GCs) 70j through 70 n . More specifically, the 
system of FIG. 1 provides multilateral communications in response to the 
receipt of one or more messages from at least one of the B/D 50|, 1M 60 h and 

15 GC70,, 

The program of FIGs. 2A-2F commences at block 101 where the TFM 
processor (FIG. 1, 10) receives an incoming message from any of the 
aforementioned parties (i.e., B/D, IM, and/or GC). In general, an incoming 
message may specify any of the following exemplary types of data: (1) a total 
quantity and value allocation for the securities transaction, (2) a block trade 
amount for the securities transaction, (3) net proceeds of the securities 
transaction, (4) maximum acceptable deviation from the net proceeds of the 
securities transaction, and (5) settlement location and/or venue. However, the 
maximum acceptable deviation need not be received in the form of an 
incoming message, and could be specified in the form of a profile that is pre- 
stored in electronic memory. The message may also includes a transaction ID 
(TRXID) uniquely identifying a given securities transaction. The messages 
submitted by parties such as B/Ds, IMs, and/or GCs may include any of Notice 
of Execution (NOE) messages, Block Order Notification (BON) messages, 
allocations messages, net proceeds messages, and settlement details messages. 
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For purposes of explanatory expediency, incoming messages may 
include some or alt of the fields shown in the table immediately following, 
wherein the variables are those which were previously discussed in conjunction 
with the illustrative cross-border securities transaction. However, more 
5 detailed data structure tables will be described hereinafter with reference to 
FIGs. 4A-4L. Assume that a buyer's B/D initiates an illustrative message with 
the following values: 



Itpjod 


BBPJD 


SEID 


SHRNO 


SHRS 


SHRSTOL 1 


[ 13424 


MLI23 


ATT 


1000 


100 


2 1 



10 where TRXID is the transaction ID, BBRID is the identity of ihe buyer's B/D, 
SEID is the identity of the security, SHRNO is the number of shares, SHR$ is 
the share price, and SHRSTOT is the maximum deviation (plus and minus) 
from the share price that the buyer is willing to accept This message does not 
have to include all of these fields. For example, the SHRSTOT field could be 
15 eliminated. The message could also include additional fields such as 
BTENDCUR, specifying the buyer's tender currency, and/or TRTXS, 
specifying tax to be levied on the transaction. 

Subsequent to issuance of the buyer's message, the seller's B/D will 
issue a message. Note that, alternatively, the seller could initiate a message 
20 first An illustrative simpli fied message issued by a seller is as follows, 
although it should be noted that a more detailed message data structure is set 
forth in FIGs. 4A-4L. 



TRXID 


SBRID 


SEID 


SHRNO 


SHRS 


SHRSTOL | 


13424 


SB555 


ATT 


1200 


105.9 
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At block 103, the program provides a confirmation prompt to the entity issuing > 
the received message, which may be B/D 5Q\, IM 60i, or GC 70|, 
5 acknowledging that the message has been received 

At block 105, the program checks to ascertain whether or not the 
received message conforms to a predefined format, examples of which are 
shown in the data structure tables above. Although any of various message 
formats maybe used to implement the invention, on occasion, data 

10 transmission errors may occur, or unauthorized parties may attempt access, and 
it would be desirable to identify such errors at the present stage, before further 
processing takes place. If the message does not conform to a predefined 
format, the entity that issued the message is alerted (block 107), and the 
program loops back to block 101. If, on the other hand, the message conforms 

15 to a predefined format, the message is considered to be an NOE (notice of 
execution) message, and the program advances to block 109. At block 1 09, an 
optional confirmation message is sent to the entity that issued the message, 
conveying the notion that the message has been accepted for further processing. 
Note that this step is not required - i.e, die entity that issued the message need 

10 not be notified that the message has been accepted. 

Next, at block 1 10, the program performs a translation of the received 
security ID (SEID) to a primary security identification code. This primary 
security identification code is fixed and determined by the market and/or the 
security itself, and could represent, for example, a standard ISIN or CUSIP 

15 security identification number. At block 1 1 1 , a test is performed to ascertain 
whether or not the incoming message includes a unique match reference 
number indicating that the incoming message relates to any previously- 
received incoming messages. If so, the program jumps to block 120, to be 
described hereinafter. If not, the program advances to block 1 12 where the 

10 data field(s) of the incoming message are compared with the data field(s) of 
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previously received message(s) to identify any previously received message(s) 
having data field(s) similar and/or identical to that of the incoming message. 

Next, at block 1 13, a test is performed to ascertain whether or not there 
is a previously-received message having some or all data field(s) with identical 
5 and/or similar content to that of the incoming message. The affirmative branch 
from block 1 13 leads to block 1 15 (to be described hereinafter), and the 
negative branch from block 1 13 leads to block 114. At block 1 14, the program 
waits for additional incoming messages and, upon receipt of a new message, 
the program loops back to block 1 12. 

10 The affirmative branch from block 113 leads to block 1 1 5 where a 

unique match reference number is assigned to the received messages having 
similar and/or identical content. The system sends notification to the senders 
of all incoming messages which were matched at block 113. The notification 
includes the unique match reference number assigned at block 115. The 

L5 incoming message is then stored for matching to future incoming messages 
(block 119). 

Block 120 is reached by an affirmative branch from block 111. At block 
120, all stored messagc(s) with unique match reference numbers referring to 
the same transaction as the incoming message are retrieved. Next, (block 121), 

50 stored profile settings and/or retrieved message(s) and/or die incoming message 
is checked for any applicable specified tolerance parameter. Matching of all 
data sets among all messages retrieved at block 120 is performed, based upon 
tolerances as specified in the stored profile and/or the incoming message and/or 
the retrieved message(s). 

!5 A test is performed (block 124) to determine whether or not there are 

any mismatches of mandatory parameters. If so, the program jumps to block 
131, to be described hereinafter. If not, the program continues to block 125 
where yet another test is performed to determine whether or not all messages 
for this transaction have been received and matched. This step could be 

0 performed, for example, by examining data structure fields to see if a field is 
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missing a value. If so, the progrtun jumps to block 129 where all transaction 
details arc routed to the local market and/or to the GC and/or to the B/D, based 
upon a profile stored in the TFM processor. The program then ends for 
purposes of this transaction. 

The negative branch from block 125 leads to block 127 where the 
program waits for additional incoming messages. If an incoming message is 
received, the program loops back to block 112. 

Block 131 is reached from the affirmative branch of block 124. An 
incompatibility message is sent to all parties identified in all messages retrieved 
at block 120. The parties are then provided with the option of cancelling, 
replacing, modifying, and/or deleting one or more messages. This functionality 
may be implemented, for example, by permitting one or more parties to issue 
new incoming message(s) which are then received by the TFM processor. At 
block 135, a test is performed to ascertain whether or not the parties modify, 
replace, delete, and/or cancel one or more messages. If so, the TFM processor 
performs matching of data based upon the replaced, cancelled, deleted, and/or 
modified message(s). The program loops back to block 124. The negative 
branch from block 135 leads to block 137 where an incompatibility message is 
sent to all parties, and the program ends for purposes of this transaction. 

The flowchart of FIGs. 2A-2F describes the process whereby, at any 
time during the post-trade, pre-settlement process, a matching mechanism 
accessible from a communications pathway matches data entered into this 
pathway. The matching process matches any of the following types of data: 
(1) matching the total quantity and value allocation, as entered by a first party, 
to total quantity and value allocation as entered by a second party; (2) matching 
net proceeds, as entered by a first party, to net proceeds, as entered by a second 
party; (3) matching maximum acceptable deviation from net proceeds, as 
entered by a first party, to maximum acceptable deviation from net proceeds, as 
entered by a second party; and (4) matching the settlement locations and/or 
venues as entered by all of the parties. However, the maximum acceptable 
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deviation need not be received in the form of an incoming message, and could 
be specified in the form of a profile that is pre-stored in electronic memory. 

The communications pathway is coupled to an indication mechanism, 
responsive to the matching mechanism, for providing a first indication as to the 
5 existence of a data match and/or the non-existence of a data match. The 
indication mechanism may include a display for indicating matches and/or 
mismatches between any of the following: (1) the total quantity /value 
allocation and the block trade amount, (2) net proceeds, (3) maximum 
acceptable deviation from net proceeds; and (4) settlement locations and/or 
10 venues. 

An optional timestamp can be applied to all incoming messages, enabling 
subsequent determination of settlement efficiencies and any possible settlement 
bottlenecks. Universal Coordinated Time (UTC), previously known as GMT 
(Greenwich Mean Time), can be used as the timestamp standard. 

15 Refer to FIG. 3 which is a table setting forth a list of abbreviations and/or 
acronyms which are used throughout the specification. Each abbreviation 
and/or acronym is associated with a corresponding definition. 

FIGs. 4A-4P set forth an illustrative data structure diagram that describes 
the informational content of messages received by the TFM processor from 

20 IMs and B/Ds. An actual message could, but need not, employ all of the fields 
shown in FIGs. 4A-4P. This data structure diagram is presented for exemplary 
purposes, to illustrate what such messages could contain. The data structure of 
FIGs. 4A-4P includes fields adapted to store information regarding the sender 
of the message, reference and trade identification details, details concerning the 

15 parties to the transaction, security identification details, additional information 
for fixed income instruments, trade details, links to another trade that was 
cancelled, links to another trade that was disputed, and additional optional 
details. 

The TFM processor (10, FIG. 1). provides support for trades involving 
JO instruments such as equities, fixed and floating rate bonds, short-term 
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instruments and simple asset and mortgage backed securities for cash 
settlement. The TFM processor is adapted to perform any of the following 
functions: 

1. Block Trade Processing 

2. Allocations Processing 

3. Net Proceeds Processing 

4. Accounting Details Processing 

5. Settlement Details Processing 

6. Free Flow Forex Processing 

7. Cancel/Replace/Delete Processing 

8. Alert and Deadline Processing 

9. Master and Reference Data 

10. Participant Profile Data 

11. Query Processing. 

Each of these functions will now be considered in sequence, commencing with 
block trade processing. 
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L Block Trade Processing 

An institutional trade typically commences when an IM makes an 
investment decision to buy or sell securities on behalf of its institutional clients. 
5 The IM places an order (block order) to buy or sell securities with a B/D. The 
B/D executes the block trade on behalf of the IM. Since the quantities involved 
in a block trade are usually very large, the B/D may execute the block trade in 
smaller lots with different prices for each lot depending on liquidity conditions 
in the market The B/D calculates the average price for the block trade once the 
10 entire block trade quantity has been executed and communicates both the 
average price and the settlement date for the block trade to the IM via a notice 
of block trade execution to the IM. The B/D may also inform the IM about the 
partial executions of the block trade and the price for each partial execution 
depending upon the preference of the IM. 
15 It is possible that a single block trade would not be fully executed within 

a single trading day. In such cases, the B/D and the IM may agree to truncate or 
warehouse the block trade up to the. quantity executed at the end of the day. 
Trading activity may occur through the use of telephones, faxes, etc., or by 
using electronic networks leveraging protocols such as FIX. However, the 
10 involvement of the TFM processor (FIG, 1) in the post trade processing cycle 
starts with the receipt of a Notice of Execution (NOE) message. 

TFM f roressor rmnctionamy 

Once a block trade has been executed, the TFM processor (10, FIG. 1) 
:5 receives a copy of the Notice of Execution (NOE) from the B/D. Normally, this 
is the starting point of the trade life cycle in the TFM processor. If the IM 
prefers to interact with the TFM processor in a "conversational' 1 mode, on 
receipt of a pending NOE for a block trade from the TFM, the IM submits a 
Block Order Notification (BON) to the TFM processor. Alternatively, the IM 
0 may submit a BON independently. 
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The trade details provided by either the B/D or the IM to the TFM 
processor regarding the block trade are set forth in a message that utilizes some 
or all of the fields which were previously described in connection with FIGs. 
5 4A-4P. The B/D submits a Notice of Execution and the IM submits a Block 
Order Notification. The TFM processor 10 (FIG. 1) timestamps the incoming 
block trade details on receipt and assigns a unique receipt reference number for 
the block trade details. The TFM processor also validates the message for 
syntax and performs the necessary edit checks. If there are any errors detected 
10 during the syntax or edit checks, the TFM processor sends an error message 
indicating the reasons for error to the sender of the message. 

If both the syntax and edit checks are successful, the TFM processor 
attempts to match the received block trade details with the unmatched trades in 
the TFM processor 10 (FIG. 1). FIG. 5 is a data structure diagram setting forth 
15 data fields that are used by the TFM for matching purposes. If die TFM does 
not find a match it stores the details of the block trade received with the status 
of "unmatched trade" in the trade database. If the TFM processor finds a 
match, it assigns a unique match reference number to the matching incoming 
messages. The previously mentioned "transaction ED", abbreviated "TRXID" 
10 could (but need not) be used for this purpose. The TFM processor then stores 
the details of both sides of the trade with a status of "Matched Trade" in the 
trade database. The status of the matching trade in the TFM trade database is 
also updated to "Matched Trade" along with the matching reference number in 
the trade database. All other fields, if specified by both the participants in the 
15 block trade details (FIGs. 41-40), are compared and a warning message is 
issued if they do not match. 

The TFM processor (10, FIG. 1) provides a "just-in-time" functionality. 
The TFM processor determines when a notice of pending transaction needs to 
be "pushed" to the counterpart. If there is no match available for the block 
30 trade details submitted by one party, the TFM processor sends a notice of 
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pending transaction to the counterpart immediately, providing the counterpart 
has opted to operate in conversational mode, If the counterpart is in 
independent submission mode, the TFM processor checks the profile of the 
counterpart for the timing of the notice of pending transaction to be sent If the 
5 timing set is beyond the deadline for the NOE and BON match, then the notice 
of pending transaction is immediately sent. If no timing has been set in the 
participant profile, the TFM processor will push the notice of pending 
transaction after a system-specified duration (for example 15 minutes). 

The TFM processor may. also be equipped with a translation mechanism by 
10 which a first security identification code specified according to a first security 
numbering agency is translated into a second security identification code for 
the same security according to a second security numbering agency. The TFM 
processor uses the following logic for matching security identification if the 
primary numbering agency code is not specified as the numbering agency code: 
:5 > The TFM processor first translates the security identification in the 
numbering agency code specified by the participant to the primary 
numbering agency code. The primary numbering agency code will be 
determined based on the type and country of issue of the security. If 
participants have specified a mutually agreed upon identification, the TFM 
:0 processor will not attempt any translation. 

> The TFM processor attempts for a match on the translated primary 

numbering agency code. 
A security numbering scheme known as ISIN (refer to FIG. 3 for the meaning 
of the foregoing abbreviation) may be utilized as the primary numbering 
5 agency code for most of the securities supported by the TFM processor. 
Example 1: (Security Identification): 
Participant A (IM) specifies a security identification in CUSIP. The TFM 
processor translates the CUSIP identification to an ISIN, which is the primary 
numbering agency code for the security. Similarly when the counter participant 
0 B (B/D) specifies a security identification in SEDOL, the TFM processor 
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translate the identification to ISIN. The translated ISINs on both block trades 
are matched 

When the Allocations are submitted, the GC is informed of the block trade 
details and the Allocation details with the security identification code originally 
5 submitted by the IM (CUSIP) and the primary numbering agency code (ISIN). 
The same principle will be applicable for sending notice of pending 
transactions to counter parts as well as sending information to interested 
parties. 

10 Tolerance Matches for Price 

Matching of price within a tolerance is applicable if both the parties 
have indicated in their profiles that they do not require an exact match on price. 
Parties (i.e., participants) can also indicate in their profiles that they need an 
exact match on the External Reference Number for carrying out a tolerance 
.5 match on the Block Gross Amount This tolerance is a participant-defined 
tolerance based on settlement currency and type of instrument. These 
tolerances can be fixed as a % and/or an absolute amount. The following 
examples illustrate various scenarios. 

o Example 1: 

Participant A (EM) and Participant B (B/D) want an exact match on price. 
Participant A submits a Block Notification for 100,000 IBM shares at an unit 
price of USD 78.50634. Participant B submits a Notice of Execution for 
100,000 IBM shares at an unit price of US 78.5063. Since both participants 
5 want an exact match on price, the TFM processor creates two unmatched 
trades. Participant A and B will have to analyse their alleged trades against 
their unmatched trades to resolve the difference. One of the participants should 
effect a replacement to change the price so that the trades can match. 

o Example 2: 
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Participant A (EM) and Participant B (B/D) have indicated that an exact match 
on price is not required. Both Participant A and Participant B wants a tolerance 
match only if the external reference #s match, Participant A submits a Block 
Notification for 100,000 IBM shares at an unit price of USD 78.50634 and a 
5 block gross amount of USD 7,850,634. Participant B submits a Notice of 
Execution for 100,000 IBM shares at a unit price of US 78.5063 and a block 
gross amount of USD 7,850,630. Participant A has specified a tolerance of 
USD 10 for equities and participant B has specified a tolerance of USD 15 for 
equities. Participant A and B have earned out the trade using FDC and have 
10 both supplied an external reference # FIX123 for the trade. The TFM processor 
matches the trade as the difference in the block gross amount (USD 4) is within 
the lowest of the tolerances of the participants (USD 10) and assigns a TFM 
match reference W TFM123 for the trade. 

15 Example 3: 

Participant A (IM) and Participant B (B/D) have indicated that an exact match 
on price is not required. Participant A and B Have indicated that an external 
reference # match is not required for a tolerance match. Participant A submits a 
Block Notification for 100,000 IBM shares at a unit price of USD 78.50634 

10 and a block gross amount of USD 7,850,634. Participant B submits a Notice of 
Execution for 100,000 IBM shares at a unit price of US 78.50 and a block gross # 
amount of USD 7,850,000. Participant A has specified a tolerance of USD 10 
for equities and participant B has specified a tolerance of USD 15 for equities. 
The TFM processor does not match both the trades as the difference in the 

!5 block gross amount (USD 634) is outside of the lowest of the tolerances of the 
participants (USD 10). Participants A and B will have to analyse their alleged 
trades against their unmatched trades to resolve the difference. One of the - 
participants should effect a replacement to change the price and the £lock gross 
amount so that the trades can match. 
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Correction of Mismatched Messages 

If participants submit messages with details that do not match, the TFM 
processor will create two unmatched trades. For example, if the IM and B/D 
have wrongly specified the security identification, but rather specified a 

5 different valid code, the TFM processor will generate two unmatched trades, 
one for each side submitting the block trade details. The IM and the B/D will 
then have to investigate their unmatched trades against their alleged trades to 
determine possible matches. To indicate the differences to counterparts (i.e. 
other parties to the transaction), participants can send a Dispute message 

L0 against an alleged trade by indicating the reference # of their unmatched trade. 
(For further details please refer to the Cancel/Delete/Replace processing 
section.) After analysing the differences, the counterpart can send a replace 
message to their side of the block trade details, which will automatically result 
in a match of the trades in the TFM processor. 

.5 

Example: 

Participant A (B/D) sends a NOE message to the TFM processor for 100,000 
IBM shares at a price of USD 78.50 against Participant B (IM) having 
reference # A1234. Participant B sends a BON message to the TFM processor 
0 against Participant A for 100,000 IBM shares at a price of USD 78.00 having 
reference # B1234. The details do not match and the TFM processor creates 
two unmatched trades, one for each side. Participants A and B also get an 
alleged trade. 

Participant A finds that the difference between the alleged trade and the 
5 unmatched trade is the price field (difference of USD .50) and sends a Dispute 
message against the alleged trade B1234 indicating that it should match with 
their trade reference # A1234. Participant B sends a replacement for trade 
B1234 changing the price to USD 78.50. On effecting the replacement, the 
TFM processor matches trades A 1234 and B1234 and assigns a TFM match 
0 reference #T1 234. 
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ff PMSetefipfrg of Trades 

The TFM processor maintain in an active trade database all matched 
trade information for up to a predetermined amount of time (e.g., 90 days). 

5 This predetermined amount of time is a TFM processor system parameter 
termed "number of days for archiving". It may be calculated from the later of 
either the settlement date or the date on which details were matched. During 
this 90-day period participants will be allowed to query, cancel or replace their 
trade details. After the 90 days, the data will be archived and will be available 

10 only for queries. 

The TFM processor cancels pending unmatched trades if either the 
entire block is unmatched or some of the Allocations pertaining to the block 
have not been enriched and matched after 30 days. This is a TFM processor 
15 system parameter called number of days for automatic cancellation of 
unmatched trades which starts at the date the block trade is input into the TFM 
processor. 

TFM Proctor Ontpute: 

!0 The TFM processor is adapted to generate any of the following outputs: 

> Error Messages, indicating the reasons for failure, will be sent if there are 
any validation failures. 

> A Trade acceptance notification is sent if the block trade is accepted by the 
TFM processor, based on the profile of the participant submitting the trade 

:5 details. 

> A notice of pending transaction may also be sent to the counterpart if an 
unmatched trade is accepted 

> If there is a match, a match notification message is sent to both the buyer 
and the seller indicating the match reference number. 

o > Any required match warnings are also notified along with the match 
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notification message. 
There are variations to this function for different types of transactions and 
processes. The following are the possible variations for different transaction 
types: 

S 

Broker-to-Broker Trades 

B/Ds can also report and match their Broker-to-Broker trades using the 
TFM processor. In this case one of the B/Ds (called the executing broker) will 

10 provide the NOE and the counterpart broker will provide the BON. The 
transaction type will be set as "Broker-to-Broker" by both sides. The TFM 
processor will not have any allocation process for Broker-to-Broker trades. 
Participants can also submit all the necessary details including net proceeds and 
settlement details, along with their NOE/BON for a Broker-to-Broker trade 

15 using a multi-part message. The TFM processor will carry out the net proceeds 
match and the channel compatibility match, as explained in subsequent 
sections, for the Broker-to-Broker trades. B/Ds can indicate in their profiles, if 
they will use the TFM processor for matching Broker-to-Broker trades. If one 
of the B/Ds in the Broker-to-Broker trade indicates that they do not want to use 

>0 the TFM processor for Broker-to-Broker trades, the TFM processor will not 
accept the Broker-to-Broker trade. 

Fund-to-Fund Trades 

Refer to FIG. 6 which sets forth information flow for a Fund-to-Fund 
!5 trade. Fund-to-Fund trades are submitted either by a single IM (to handle 
internal crossings between funds), or by two different IMs (if they have traded 
using electronic networks such as Instinet or E-crossnet). Fund-to-Fund trades 
are handled by the TFM processor as two institutional trades. Both sides of the 
Fund-to-Fund trade will be reported as institutional trades against a virtual 
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broker, which is either a clearing account providing internal crossings or. an 
institution providing the fund-to-fund crossing services (such as E-crossnet). 
FIG. 6 explains the handling of a Fund-to-Fund trade. All of the inputs are 
indicated as Fund-to-Fund trade in the Trade Transaction Type. The common 
5 virtual broker can link the two sides of the fimd-to-fund trade using a link 
reference number. 



Basket/Portfolio or Program Trading 

Participants (parties) report and match basket/portfolio or program 
;o trades as individual institutional trades relating to each underlying security of 
the basket/portfolio or program. Participants specify a common basket/portfolio 
or program reference number, and will designate the trade transaction type as 
"Basket/Portfolio or Program" trade A typical basket/portfolio or program 
trade will be a pre-allocated trade where the B/D will specify the allocations for 
5 the underlying institutional trades. The TFM processor will support queries to 
participants based on the basket/portfolio or program trade reference number. 

2. Allocation Processing 

IMs buy and sell securities on behalf of their institutional clients 
0 (pension funds, mutual funds, insurance funds, etc.) The IM who has placed a 
Block Order identifies the clients on whose behalf the buy or the sell decision 
has been made. The IM allocates the quantity of securities bought or sold 
among its various clients and informs the TFM processor through one or more 
Allocation messages. Allocation messages are sent to the TFM processor at the 
5 same time or after the BON is submitted. 

TFM Processor Functionality 

IMs submit allocation messages to the TFM processor in accordance with 
one of the following procedures: 
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(A): The IM allocates the trade as soon as the Block Order i* submitted to 
the TFM processor. The Allocation message may be sent to the TFM processor 
along with the BON in a multi-part message or the Allocation may be sent to 
the TFM processor after the BON is submitted as a separate message. In both 
5 cases, the TFM processor may receive the Allocations before or after the BON 
is matched with the NOE. The TFM processor matches the Allocation quantity 
with the BON quantity. Information flow for this allocation process is shown 
in FIG. 7. 

(B): The IM, upon receipt of communication from the TFM processor 
10 of Pending Notice of Execution, may affirm the trade by submitting the BON 
in conversational mode and subsequently submitting the Allocations. In this 
case, the TFM processor first matches the trade (BON with NOE), and then the 
TFM processor matches the Allocation quantity with the trade quantity. 
Information flow for this allocation process is shown in FIG. 8. 

15 

f artja) Allocations 

IMs may not have the complete client information for all of the 
Allocations. In cases where the IM has incomplete information regarding a 
particular Allocation, the IM can submit Allocations whose details are 
20 complete to the TFM processor. The Allocations for the entire trade quantity 
can be provided as part of a single message or through multiple messages, as is 
shown in the information flow diagram of FIG. 9. 
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When the EM sends Allocations for a trade in more than one 
message, these Allocations are called Partial Allocations. Partial Allocation 
messages can be submitted when the BVf identifies the clients) for the 
Allocation- The IM gives an unique sequence number for every Allocation 
5 contained in the messages submitted Each of the Allocation messages will 
specify the quantity allocated in that message. The TFM processor will 
compare for each partial Allocation message, the total quantity of Allocations 
in the message with the unallocated quantity for the trade. 

10 I.npntjnfqrmation 

Refer to FIG. 10, which is a data structure diagram describing . 
information provided by the IM to the TFM processor as part of an Allocation 
message. The TFM processor titnestarnps the incoming Allocation message 
upon receipt and assigns it a unique receipt reference number. The TFM 
LS processor also validates the message for syntax and performs the necessary edit 
checks. The TFM processor validates the Trade Reference number given in the 
Allocation message that is submitted by the participant. There should be an 
existing trade within the system with the same reference number and the same 
counterpart. When all Allocations are part of a single message, the TFM 
:0 processor matches the total quantity of the Allocations to the trade quantity. 

When Partial Allocations are received by the TFM processor, the TFM 
processor keeps track of the Allocations received for the total trade. When the 
total quantity of Allocations received matches the total trade quantity, the 
Allocation process is completed and the trade status is updated as "Matched 
5 Allocated Trade" or Unmatched Allocated Trade" depending on whether the 
trade is matched or not If the quantity allocated in the message is more than 
the unallocated quantity for the trade before the arrival of the message, the 
message being processed is treated as 'Tn Error/' Once the Allocation message 
has passed the total quantity check, each allocation within the message is 
) validated for content. Only the allocations failing the validations will be 
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rejected by the TFM processor. The remaining allocations will be processed 
normally by the TFM processor. 



Example 1: 

5 The IM has placed a block order for 100,000 shares for which partial 

Allocations are being submitted. The first Allocation message is submitted 
with the following control fields: 
Quantity allocated in this message: 25.000 
(Reference number 1 & 2) 

10 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. The second Allocation message is submitted with the 
following control fields: 
Quantity allocated in this message: 25,000 
L5 (Reference number 3 & 4) 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. Another Allocation message is submitted with the 
following control fields: 
[0 Quantity allocated in this message: 40,000. 
(Reference number 6 & 7) 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. TFM processor finds that the trade is not fully allocated. 
IS Another Allocation message is submitted with the following control fields: 
Quantity allocated in this message: 10,000 
(Reference number 5) 

The TFM processor verifies that the quantity allocated is not more than the 
0 unallocated quantity. When the quantity allocated equals die unallocated 
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Trade*' or "Unmatched Allocated Trade" depending on whether or not the 
BON/NOE match has taken place. 

Example 2: 

5 The IM has placed a block order for 100,000 shares for which partial 
Allocations are being submitted The first Allocation message is submitted 
with the following control fields: 

Quantity allocated in this message: 25,000 

(Reference number 1 & 2) 

0 The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. The second Allocation message is submitted with the 
following control fields: 

Quantity "allocated in this message; 25,000 

(Reference number 3 & 4) 

5 The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. Another. Alloeaticn meecage is submitted with the 
following control fields: 

Quantity allocated in this message: 40,000 

(Reference number 5 & 6) 

1 The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. Another Allocation message is submitted with the 
following control fields: 

Quantity allocated in this message: 20.000 

(Reference number 7) 

TFM processor verifies that the quantity allocated (20,000) is more than ihe 
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unallocated quantity (10,000). TFM processor marks the Allocation Message as 
"In Error." 



Example 3: 

5 The IM has placed a block order for 100,000 shares for which partial 
Allocations are being submitted. The first Allocation message is submitted 
with the following control fields: 
Quantity allocated in this message: 25,000 
(Reference number 1 & 2) 

10 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. The second Allocation message is submitted with the 
following control fields: 
Quantity allocated in this message: 25,000 
1 5 (Reference number 3 & 4) 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. Another Allocation message is submitted with the 
following control fields: 
20 Quantity allocated in this message: 40,000 
(Reference number 5 & 6) 

The TFM processor verifies that the quantity allocated is not more than the 
unallocated quantity. Another Allocation message is submitted with the 
25 following control fields: 

Quantity allocated in this message: 10,000 
(Reference number 8) 

The TFM processor verifies that the trade is fully allocated, but finds that 
30 sequence number 7 is missing. TFM processor sends a warning to the IM 
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informing about out-of-sequence Allocations. 

Account Number Cross-Referencing 

An allocation message that the TFM processor receives from an IM may 
5 provide the Account Number of the client as per the IMs internal records, 
and/or pursuant to the GCs client account number. The TFM processor could, 
but need not, perform any cross-referencing of the IM's account number to the 
B/D's internal account numbers. To enable the B/D to cross-reference between 
the IM's number and the B/D's internal reference number, the IM can also 

10 provide in the Allocation message the access code relating to the vendor's 
system where the account number is registered, if it is indeed registered (e.g., 
in Alert, SID, etc.) The TFM processor will send this information to the B/D as 
part of the Allocation Notification. The B/D will interface with the vendor 
system for internal account set-up and cross-referencing purposes. The GC 

15 will receive the IM's and its own account numbers, as provided by the IM on 
the allocation. 

It is possible to utilize a new standard numbering scheme to identify 
accounts/portfolios. This would involve the creation of an "Account/Portfolio 
Registering Agency" that would allocate unique account numbers for each 

20 account/portfolio that an institutional investor (e.g., a mutual fund, a pension 
fund) would want to register. This registering agency would collect the 
minimum amount of information about the account/portfolio that is needed for 
IMs, B/Ds, and GC to recognize this entity. The IM and the GC would use the 
unique number (directly or by cross-Teference). The association of this unique 

25 number with the IM BIC code would uniquely define the account for a B/D. 
As per the proposed scheme, the IM will identify their client account numbers 
as "Portfolio X," the GC will identify their client account as "Portfolio X" and 
the B/D will identify their client account as "Portfolio X at IM Y." There are 
several potential consequences related to this proposal. The design of the TMF 

30 described herein will allow for such a possible development in the future. 
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The transition from the current situation to a new account numbering 
system could proceed as follows: 

> In the early phase of the proposed scheme, the IM will submit its account 
5 number, the GCs account number and a GSTPA (Global Straight Through 

Processing Association) account number, if available. The B/D will receive 
from the TFM processor, the IM's account number and the GSTPA account 
number, if provided by the IM. The GC will receive from the TFM 
processor, the IM's account number, the GC's account number and the 
10 GSTPA account number, if provided by the IM. 

> As the proposed scheme develops, the IM submits the GSTPA account 
number only as part of the Allocation message. The B/D and the GC will 
receive the GSTPA account number from the TFM processor as part of the 

15 Allocation Notification and will do the required cross-referencing internally 
in their own applications. 

Security Identification 

The TFM processor provides one or more security identification 
20 messages to the GCs. These messages include a security identification number 
in the numbering agency code supplied by the IM, and/or in the primary 
numbering agency code translated by the TFM processor. Translated codes are 
provided in the event that the number received from the IM is not a 
prespecified primary code to be utilized by the TFM processor, such as, for 
25 example, ISIN. 

Example 1: The IM and the B/D have submitted the trade details m ISIN, 
which is prespecified as the primary numbering agency code for the security. 
The TFM processor will notify the Allocations with the details of the security 
30 in ISIN, which was used by the IM to report the trade. 
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Example 2: The IM submits the security details in CUSIP. The B/D submits 
the security details in SEDOL. As the TFM processor has already translated the 
CUSIP and SEDOL to ISIN (which is the primary numbering agency code) 
5 before the trade match is done it will notify the GC of the security details in 
ISIN and CUSIP, which was the code supplied by the IM. 

Settlement Location 

The B/D provides an NOE message to the TFM processor specifying the 
10 setdement location that was explicitly or implicidy included in the trade 
agreement. This information will be relayed with each Allocation as it is sent 
to the GC. 

Outputs 

15 The following are output messages generated by the TFM processor for the 
aforementioned allocations process. 

> The TFM processor sends one or more notification messages to the B/D 
regarding the Allocations received from the IM. The notifications are sent 
for every Allocation accepted by the TFM processor. The notifications to 

20 the B/D will include the particulars of each Allocation. This enables the 
B/D to submit the Net Proceeds and Settlement Details for each Allocation. 
This message is sent to the B/D only after the trade is matched. 

> The TFM processor sends one or more notification messages to the relevant 
25 GC on acceptance of every Allocation. The notification to the GC will 

include all the particulars of the trade except the trade quantity (as per the 
BON or the matched trade, if the trade is matched) and the Allocation 
details as per the Allocation message. This enables the GC to prepare for 
die setdement very early. As the settlement location information from the 
30 NOE is vital information for the GC, it would be better to send the 
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Allocation when the NOE and BON have matched. If the trade is not yet 
matched and the GC had indicated a desire to receive Allocations right 
away in its profile, the notification will indicate that the trade is in 
unmatched status and will have to be sent again with the settlement location 
5 as soon as it is available (i.e., after the NOE/BON match occurs). 

> If the IM or the B/D has appointed a third party to submit net proceeds, the 
TFM processor sends a message specifying the details of the trade and the 
Allocation details to this third party. This enables the substituting party to 

10 compute the net proceeds and submit them to the TFM processor. 

> If the B/D or the GC has appointed a third party to submit settlement 
details, the TFM processor sends a message specifying the details of the 
trade and the Allocation details to this third party. This enables the 

15 substituting party to submit the settlement details to the TFM processor. 

> Error messages indicating the reasons for failure will be sent if there are any 
validations failures. An error message can be at the level of the entire 
allocation message submitted by the EM if the message fails the total 

20 allocation quantity check. Error messages can also be at the level of an 
individual Allocation if they fail any content check (e.g., invalid GC 
identification, etc.) 

> Allocation acceptance success messages will be sent when Allocations are 
25 successfully accepted by the TFM processor. The acceptance success 

messages are at the level of each individual allocation submitted. 

> When the block trade is fully allocated a Status Change message, indicating 
that the trade is folly allocated is sent to both the IM and the B/D. This 

30 message to the B/D is sent only after the trade is matched. 
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The data structure diagram of FIG. 1 1 summarises the input and the output 
messages utilized throughout the above-described Allocations process. 

5 Step Out Trades 

A trade where the IM instructs the executing B/D (step out broker) to 
allot a portion of the trade to another B/D (step in broker) is called a "step out 
trade " The IM generally allots these trades to satisfy soft dollar arrangements 
it has with the step in brokers. The executing B/D who receives (buy trade) or 
10 delivers (sell trade) all the quantity of the trade and breaks out the trade 
according to the direction of the IM is called "step out broker." A non- 
executing B/D indicated by the IM on one or more Allocations who is 
responsible for the delivery of the quantity allotted in the Allocation is called a 
"step in broker. " 

15 As part of an Allocation message, the IM will indicate whether a 

particular Allocation has to be stepped out. If the Allocation has to be stepped 
out, the message indicates the identification of the step in broker. Upon receipt 
of the stepped out Allocation, the TFM processor will update the current trade 
quantity by the stepped out quantity and create new alleged trade details for the 

20 stepped out quantity. The trade details for the new alleged trade (BON) and the 
Allocation details will be sent to the step in broker. The step in broker will 
submit the trade details (NOE) to affirm that the trade stepped out in its favour. 

The TFM processor will mark the Allocation sequence number of the 
original block trade as stepped out. Any deletions or replacements of the 

25 original trade will not impact the new trade created for the step out Allocation. 
The alleged new trade created by die step out Allocation will have a TFM 
processor-generated trade reference number (starting with "T"). This will be 
treated as a completely new trade and any deletions or replacements will be 
independently applicable to this trade. The link between the original block- 

30 trade and the new trade, arising out of step out, will be maintained at the 
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Allocation level of the original trade. 

The step out/in brokers can specify in their profiles as to whether the 
Broker-to-Broker transaction relating to the step out trade should be handled by 
the TFM processor. Based on the profiles of the step out/in brokers, the TFM 
5 processor will also create new (if both step out/in B/Ds indicate that they want 
to handle the broker-to-broker leg using the TFM processor) Broker-to-Broker 
trade details for the step out trade between the stepped out broker and the step 
in broker. The TFM processor will send these details on behalf of the stepped 
out broker to the step in broken The step in broker in turn will submit the trade 
10 details to affirm the trade. This Broker-to-Broker trade will be treated as a 
completely new trade and all processes will be independently applicable to this 
trade. The information flow diagram of FIG. 12 explains "step out' 1 trades 
from the perspective of a u stepping-in" B/D. 

15 Example: 

> IM, ABC places a buy order with broker XYZ for 1 00,000 VODX. 

> The Allocation details are as follows: 



20 Quantity Account Name Step out indicator 

10,000 A 123 None 

30,000 B456 None 

10,000 C789 Step out to B/D 1 

25 30,000 D012 None 

20,000 E345 Step out to B/D 2 



> Upon receiving the Allocations, the TFM processor changes the quantity of 
the trade between ABC (IM) and XYZ (B/D) to 70,000 (trade quantity 
30 1 00,000 - step out quantity 30,000) 
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> The TFM processor informs the stepped out broker of all the Allocations 
including the Allocations that were stepped out* 

> The TFM processor creates a Notice of Pending transaction against B/D 1 
(Step in broker 1) for 10,000 shares of VOD.L at the executing price with 

5 ABC (DM). 

> The TFM processor creates a Notice of Pending transaction against B/D 2 
(Step in broker 2) for 20,000 shares of VOD.L at the executing price with 
ABC(IM). 

> Both the steps of brokers B/D 1 and B/D 2 should submit Notices of 
10 Execution (sell) messages with ABC as a counterpart for the trades stepped 

<xit in their favour and for which the TFM processor has sent out a 
notification message (a Notice of Pending Transaction). 

> The TFM processor will also create the following Broker-to-Broker 
transactions: 

15 > Seller XYZ Buyer B/D 1 10,000 VOD.L 
> Seller XYZ Buyer B/D 2 20,000 VOD.L 

> Both the transactions will be at the executed price of XYZ. Execution of 
the original block trade and a notice of pending transaction are sent to B/D 
1 and B/D 2. 

20 > Both the step in brokers B/D 1 and B/D 2 should submit the Notice of 
Execution (buy) with XYZ for the trades stepped out in their favour and for 
which the TFM processor has sent a Notice of pending transaction. 

> B/D 1 will submit the Net Proceeds details for 10,000 shares, B/D 2 will 
submit the Net Proceeds details for 20,000 shares and XYZ will submit the 

25 Net Proceeds for the remaining Allocations of 70,000 shares. They will 
also submit the settlement details for these Allocations respectively. 

> ABC (IM) will submit the Net Proceeds details for all the Allocations and 
the GCs for the allocated client will submit the settlement details. 

> The Broker-to-Broker deal between B/D 1, B/D 2 and XYZ will be treated 
30 like any other Broker-to-Broker deal. The TFM processor will create this 
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Broker-to-Broker deal based on the profile settings of Broker XYZ, B/Dl 
and B/D2. 



Percentage Allocations 

5 The TFM processor need not support percentage Allocations. 

Allocations may be received as an absolute quantity. 

Variations 

The impact of various transaction types during the Allocation process 
10 are as follows: 

)Pre-AHoc*ted Trades 

The IM and the B/D will indicate in their respective BON and NOE 
messages that the trade is a pre-allocated trade and then the Allocations will be 
submitted by the B/D. The B/D will submit the list of Allocations to the TFM 

15 processor on behalf of the IM, if the B/D has an agreement to do so with the 
IM. If the B/D submits Allocations on a trade that has not been indicated as 
pre-allocated, the allocation message will be rejected by the TFM processor. 
Typically for basket/portfolio or program trades, the B/D will submit the 
Allocations. The B/D submits the Allocations to the TFM processor for the 

20 trades for which it has received Allocations outside the TFM processor 
environment from the IM. 

The B/D can submit the Allocations to the TFM processor either with 
the Notice of Execution as a multi-part message or by a separate message. The 
B/D can also submit Net Proceeds along with these Allocations. For a given 

25 trade, the Allocations can come from either the IM or the B/D, However, there 
will be no possibility of allocations coming from both the IM and the B/D (i.e.> 
some of the Allocations coming from the B/D and remaining corning from the 
IM). If the IM submits Allocations for a trade that has been identified as pre- 
allocated, the Allocation message will be rejected by the TFM processor. 
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Similarly, if the B/D submits If the TFM processor receives Allocations for a 
trade that has not been identified as a pre-allocated trade, the TFM processor 
will reject the Allocations. 

The Allocation details coming from the B/D will have the details of the 
5 EM Client Account, but the B/D may or may not provide some details of 
Allocations (i.e., the GC Id, the GC Client Account Number, commission type, # 
Broker of Credit, etc). The TFM processor, on receipt of Allocation details 
from the B/D, will forward the incomplete Allocations to the IM. The IM will 
complete and enrich the Allocations by submitting a new Allocation message 

10 with the particulars of the GC Id, the GC Client Account Number, FX-related 
instructions, Commission type, etc. This will complete the Allocation process. 
The IM cannot change die quantity of the Allocations submitted by the B/D. 

The B/D can also submit a complete Allocation message. If the B/D has 
submitted the Allocations, complete with the GC particulars, the TFM 

15 processor will send a Notification of Allocations to the IM. With reference to 
FIGs. 13 and 14, the B/D can replace the Allocation particulars it has 
submitted. However, die IM cannot replace the quantity of the Allocations 
submitted by the B/D. 

Prpker-tq-proker Trades 

20 The aforementioned allocation process need not be utilized for Broker- 

to-Broker Trades. Instead, the TFM processor proceeds directly to the net 
proceeds and settlement details matching processes for Broker-to-Brokcr 
trades. 

Fund-to-Fund Trades 

25 A Fund-to-Fund trade is reported to the TFM processor as two 

independent trades with a common link reference number and a common B/D. 
The TFM processor will receive Allocations from the IM and process them like 
any other institutional cross-border trade. No process change is envisaged for 
Allocation processing for fund-to-fund trades. This information flow process 
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(refer to FIG. 15) enables Allocations on the buy side of the fund-to-fund trade, 
and Allocations on the sell side of the fund-to-fund trade, to be cleared by an 
agent of the IM (common Virtual Broker). 

Basket/Portfolio or Program Trades 

5 This trade type carries a unique basket reference number. The trade 

details relating to every security comprised in the basket will be linked with 
this basket reference number given by the B/D. The IM provides allocations on 
an absolute basis for each security contained in the basket Each allocation 
message has the particulars of the separate securities contained in the basket. 

10 

3. Net Proceeds Processing 

Subsequent to the submission of allocations, the IM and the B/D submit 
the net proceeds details to the TFM processor. There can be a third-party 
substitution on behalf of the IM or the B/D. The IM and die B/D calculate the 

15 net proceeds for each allocation to the block trade. The net proceeds are 
computed after adjusting for various charges such as commissions, fees, taxes, 
other, etc., from the gross proceeds. The net proceeds from the IM and the B/D 
are matched either exactly or within tolerances before they are released to the 
local market. The approach to tolerances respects the operational preferences of 

20 as many parties as possible while at the same time enabling the maximum 
number of transactions to flow through the system without intervention. The 
optimal approach also limits the number of required adjustments to internal 
records, particularly if such adjustments are not material in nature; 

25 TFM Processor Functionality 

The TFM processor accepts and matches the net proceeds submitted by 
both the IM and the B/D. The net amounts can match within market and user 
tolerances set by the participants. If a user tolerance match is outside the 
market tolerance, then the non-prevailing party will be informed of the 
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prevailing amount and one net amount figure is released to the local market. 
This will ensure that the trade matches in the local market. The TFM processor 
will not change the underlying details such as commissions, fees, taxes, or the 
like. The TFM processor notifies the affected party of the net amount change so 
5 that they can adjust their internal records accordingly. In such cases, the TFM 
processor will populate a field indicating the amount of the net amount 
difference. This will provide the participant with the discretion to adjust 
elements of its internal records (commissions, fees, taxes, etc.) as is 
appropriate. 

10 

Inpnt Information 

The information flow diagram of FIG. 16 sets forth illustrative 
information received by the TFM processor from the IM and the B/D pursuant 
to the Net Proceeds Matching Process. This information informs the TFM 
15 processor of the net proceeds details. The B/D and the IM can submit net 
proceeds details for some or all of the Allocations as part of a single message 
or through multiple messages. 

Net Proceeds Mes^ge Acceptance 

20 The TFM processor timestamps the incoming Net Proceeds details on 

receipt and assigns a unique receipt reference number for the message. The 
TFM processor also validates the message for syntax and performs the 
necessary edit checks. If there are any errors detected during the syntax or edit 
checks, the TFM processor sends an error message indicating the reasons for 

25 error to the sender of the message. The TFM processor also performs the 
necessary mathematical checks to ensure the accuracy of the information 
submitted by the participants (i.e., Net proceeds equals gross proceeds plus or 
minus all charges such as commissions, fees, etc., depending on the whether 
the IM is buying or selling.) 

30 The TFM processor also computes the gross proceeds for the allocation 
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based on the price for the block trade and the allocated quantity. The TFM 
processor will validate if the computed gross proceeds amount is the same as 
the one specified by the participant. Since the price can be quoted with a 
precision of 10 decimal places and the gross proceeds can only be specified 
5 with a precision that is the maximum allowed for the settlement currency, due 
to rounding errors the comparison may not be exact. The TFM processor will 
compare the gross proceeds computed and the one supplied by the participant 
within a tolerance value that will address this rounding issue. If the comparison 
within the tolerance value fails the TFM processor will reject the net proceeds. 

10 

Net Frpgefids Match 

If both the syntax and edit checks are successful, the TFM processor 
attempts to match the net proceeds amounts submitted by each party at the 
allocation level. 

15 The following fields are used by the TFM processor to compare the net 
proceeds details at the allocation level: 

> TFM processor Match Reference Number 

> Allocation Sequence Number 

> IM Client Account Number or GSTPA Account Number 
20 > Allocation Quantity 

The above comparisons look for exact matches. In addition, the following field 
is matched, either exactly or within tolerance, at the allocation level: 

> Net amount 

25 For purposes of the match, the net amount in settlement currency is used. 

The charge types (i.e., Commissions, Taxes, Fees, Stamp Duty and other 
charges) are not matched but are available to assist with repairs in the event of 
a mismatch of the net amounts. 

30 Tolerance Match 
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Tolerance matches are performed at two levels: 

• Market (Maintained by a TFM processor administrator, for every settlement 
location/settlement currency combination) 

• Participant /User 

5 - Bilateral (Maintained by a participant for specific counterparts) 
- Unilateral (Maintained by a participant for all counterparts) 

The tolerances for the net proceeds match may be percentage based, 
absolute or a combination thereof In a combination situation, tolerance is a 
10 percentage of the settlement amount subject to a limit in absolute value for the 
settlement currency. For example, the tolerance can be specified as follows: 
Percentage tolerance: 0.1% subject to an upper limit of 50 USD. 

Market Tolerance Match 

15 A key feature of the TFM processor is that the net amount released to the 
local market will match within local market tolerances. Therefore, net amounts 
are first matched based on market tolerance- The market tolerance is 
maintained at the following level: 

• Settlement Location 
20 • Settlement Currency 

If the net amounts match within the local market tolerance, the trade allocation 
flows through the system even if the net amounts and underlying details are 
slightly different This will ensure that the trade allocation will match in the 
local market and will avoid a situation where one party will need to adjust its 
internal records for immaterial discrepancies. The TFM processor will use the 
settlement location specified on the NOE to determine which market tolerance 
to apply. 

However, during the settlement details enrichment process, a settlement 
location other than the one specified in the NOE may be agreed upon between 
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the B/D and the GC or the GC could propose a bridge location that is 
compatible- If a settlement location is proposed by the GC which is different 
from the one specified in the NOE, and the net proceeds have matched within 
market tolerance, then the TFM processor will re-attempt a net proceeds match 
5 with the details of the GCs proposed different settlement location or with the 
details of the bridge between the GCs proposed location and the settlement 
location specified by the B/D in the NOE. The TFM processor will only re- 
attempt the Net Proceeds match if the market tolerance for the new settlement 
location is lower than the market tolerance for the previous settlement location. 

10 

Example 1 

For a trade allocation, 
Buyer Amount is 500 
Seller Amount is 525 
1 5 Market tolerance is 25 

This is treated as a MATCH. 

Example 2 

For a trade allocation, 
20 Buyer Amount is 500 
Seller Amount is 530 
Market tolerance is 25 

This is treated as a FAKED MATCH within market tolerance. However, they 
may match within user tolerance established in the participant profiles of the 
25 buyer and the seller 

U^rTpfcPMice Match 

User tolerances are specified in participant profiles. Participants' 
tolerances will be the same or larger than market tolerances. If the net amounts 
30 are within user tolerances, the trade allocation flows through the system. FIG. 
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17 is a Prevailing User Tolerance Decision Table for determining the tolerance 
to be applied on the buyer's and the seller's side for the purpose of matching the 
net proceeds within a user-defined tolerance. The decision table of FIG. 17 
should be utilized because none, one, or both of the following user tolerance 
5 values may be specified for the buyer and the seller: 

• Bilateral tolerance 

• Unilateral tolerance. 

The following examples illustrate the manner in which the Prevailing User 
Tolerance Decision Table of FIG. 17 maybe employed: 

10 

Example 1 

Buyer A has set the following in the participant tolerance profile: 
Bilateral tolerance value for Seller B for the net proceeds: 50 USD 
Unilateral tolerance value for the net proceeds: 30 USD 

15 

SellerB has set the following in the participant tolerance profile: 
No bilateral tolerance value set for Buyer A for the net proceeds 
Unilateral tolerance value for the net proceeds: 25 USD 

20 As per the above decision table, the following tolerance values are applicable: 
Buyer A: 50 USD 
Seller B: 25 USD 

Example 2 

25 Buyer X has set the following in the participant tolerance profile: 
No Bilateral tolerance value set for Seller Yfor the net proceeds 
Unilateral tolerance value for the net proceeds: 25 USD 

Seller Yhas set the following in the participant tolerance profile: 
30 No Bilateral tolerance value set for Buyer X for the net proceeds 
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No Unilateral tolerance value set for the net proceeds 



As per the above decision table, the following tolerance values are applicable: 
Buyer X: 25 USD 
5 SellerY.O 

If there is a match within user tolerance, the TFM processor will ensure that the 
same net amount will be released to the local market for both the IM and the 
B/D. If a match of the net amounts occurs within user tolerances, but not 
10 exactly, the TFM processor will indicate the net amount difference for the non- 
prevailing party. The non-prevailing party will be made aware of the 
discrepancy so that they can adjust their internal records. For this purpose, 
each participant will specify one of the following three preferences in their 
profiles: 

15 1 . Always use my amount in the event of a match within user tolerance (Mine) 

2. Always use my counterpart's amount in the event of a match within user 
tolerance (Counterpart's). 

3. I am neutral as to which amount prevails (Neutral), 

(It is recommended that B/Ds set their preferences to Neutral.) 

20 

FIG. 18 is a decision table for determining the prevailing amount of the 
trade and the match status for each of various useT tolerance match results. The 
various scenarios have been explained with examples, which are referenced in 
the table. 

25 FIG 19 is a flowchart that depicts the Net Proceeds Matching Process as 

implemented by the TFM processor. 

FIGs. 20-39 set forth examples of various Net Proceeds Matching 
Process results as determined by the process of FIG. 19. Basically, if die 
matching process "fails", the TFM processor stores the net proceeds details 

30 received and the allocation with a status of "Net Proceeds Match Fail." The 
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TFM processor notifies both parties about the match failure and the need to 
correct the Net Amounts. 

If the comparison succeeds, then the TFM processor stores the details of the net 
proceeds details received and the allocation with the status as "Net Proceeds 
5 Matched" 

If there is no Net Proceeds message available for the trade allocation from the 
counterpart, depending on the processing preferences of the counterpart, the 
TFM processor may send a notice of pending transaction for Net Proceeds. 

10 Outputs 

The following are possible outputs generated by the TFM processor 
pursuant to the Net Proceeds Matching Process: 

> Error Messages indicating the reasons for failure will be sent if there are 
any validation failures along with the net proceeds details received by the 

15 TFM processor. 

> A notice of pending transaction for Net Proceeds will be sent to the 
counterpart if the counterpart has not submitted the net proceeds. 

> A Net Proceeds acceptance message will be sent to the IM or the B/D when 
the Net Proceeds are accepted by the TFM processor along with the details 

20 of Net Proceeds message received. 

> An Error message indicating reasons for error will be sent if there are any 
match errors and there will be a comparison of all the components that 
constitute the net proceeds. 

> A status change message will be sent to the IM and the B/D once all the Net 
25 Proceeds have matched. 



If there is a match, the following notification is sent to the IM, the B/D and the 

GC: 

> Trade Match Reference # 
30 > Trade Reference # 
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> Trade Version # 

> Allocation Sequence # 

> Trade Allocation Version # 

> Net Proceeds Version # 
5 > IM Client Account # 

> GSTPA Account # 

> Allocation Quantity 

> Settlement Currency 

> "Prevailing Party Identification 

10 > "Prevailing Net Amount for the Allocation 

> "Prevailing Party's Gross Amount for the Allocation 

> "Prevailing Party's Broker Commission 

> "Prevailing Party's Accrued Interest 

> "Prevailing Party's Local Taxes 
15 > "Prevailing Party's Stamp Duty 

> "Prevailing Party's Registration Charge 

> "Difference between the Prevailing Party's Net Amount and Party's Net 
Amount 

20 "In the case of the exact match, the IM and the B/D will get their own amounts 
and the difference amount will be set to zero and the GC will get the IM's 
amounts. In the case of a match within market tolerance, the IM and the B/D 
will get their own amounts and their counterparts amounts to facilitate 
reconciliation and the GC will get the IM's amounts. 

25 

Variations 

There are variations inherent in the Net Proceeds Matching Process for 
different types of transactions. The following types of transactions illustrate 
some of the possible variations: 
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BrokeMo-Broker Trade 

As there arc no allocations in Broker-to-Broker trades, the TFM 
processor will create a dummy allocation. The B/Ds could have given the net 
proceeds details along with the block trade details as part of a multi-part 
5 message. In this case the TFM processor, after successful acceptance of the 
block trade details, will invoke the net proceeds process. 

4. Accounting Information Processes 

Many of the data elements used to effect the settlement of a trade are 
10 also used for accounting purposes. In addition, there are a very small number of 
optional data elements that are specific to the accounting function. The IM 
supplies these data elements along with a Block Order Notification message. 
The IM may also send an Allocations message and/or a Net Proceeds message 
to the TFM processor, and/or the IM may receive an Allocations message 
15 and/or a Net Proceeds message from the TFM processor. Using the 
information (BON, allocation, net proceeds, accounting details), the TFM 
processor creates an "accounting message" to route the accounting information 
to the Accounting Agent at, or before, the deadline. The Accounting Agent is 
an entity that provides accounting services to a Portfolio, a Fund or a Client 
20 that is served by the IM. There could be more than one Accounting Agent 
(Interested Party) associated with an account. Accounting data may also be 
delivered to other interested parties, who are identified by the IM in its profile. 

Acq>untfpg Deadline 
25 The IM and Accounting Agent maintain deadlines in their profiles for 

sending the accounting information to the Accounting Agents. Refer to the 
Profiles section and the Alert and Deadline Processing section for the details on 
deadlines for accounting information. 
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Accounting Data 

5 > Input Message 

Hie IM will send the accounting data at the level of the BON, Allocations and 
Net Proceeds messages. The TFM processor does not perform a validation 
check on these accounting-specific fields, except for syntax. The input data for 
accounting is included with the BON, Allocations and Net Proceeds message 
10 inputs described in the earlier sections. 

> Output Message 

The TFM processor sends the accounting information to the Accounting Agent 
before or at the deadline set for the IM's client. The accounting information 
15 includes the accounting data that is sent by the IM as well as the TFM 
processor-enriched data for the trade, the allocation and the net amount details 
(quantity, price, gross amount, net amount, commission, fees, tax and interest, 
etc.) Please refer to Appendix C for the data elements that will be sent to the 
Accounting Agent, 

20 

The accounting data is sent to the Accounting Agent at or before the deadline 
in the following cases: 

> The net proceeds have been matched in the TFM processor and the IM has 
25 provided the accounting information. This is referred to as the confirmed 

reporting to the accounting agent (This information is sent immediately, 

prior to the deadline.) 
The IM has submitted the allocations, the accounting information and the net 
proceeds. In this case, the Accounting information is released to the agent 
30 based on the IM 1 s data. The message to the Accounting Agent will indicate that 
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the net proceeds have not matched. This is known as unconfirmed (soft)" 
reporting to the Accounting Agent. This information is sent at the deadline 
according to the IM's profile. 

5 > The accounting infonnation and the net proceeds details have been 
submitted, however, the net proceeds of the B/D and the IM do not match. 
In this case the TFM processor releases the accounting information based on 
the IM's net proceeds data, or the B/D's net proceeds data, depending on what 
the IM has set in the profile for that client and Accounting Agent. The TFM 
10 processor sends a warning message to the IM and the Accounting Agent that 
the net proceeds have not matched (This infonnation is sent at the deadline 
according to the IM's and Accounting Agent's profiles.) This is also referred to 
as unconfirmed (soft) reporting to the Accounting Agent 

15 > In the case where the net proceeds have not yet matched, the TFM 
processor will send a confirmed reporting to the Accounting Agent once the 
net proceeds match. The Net Amounts could change the financial 
components of the settlement data and thus also impact the accounting data. 
When this occurs, the changed details are released to the Accounting Agent, 

20 and will be identified as a change to the previous unconfirmed reporting 
done by the TFM processor. (This will lead the Accounting Agent to 
reverse the trade in its records and to re-book it) 

> If there are any replacements or corrections to a trade, the allocation, or the 
net proceeds details, the changed details are notified to the Accounting 

25 Agent The TFM processor will also clearly indicate if the change is on an 
unconfirmed (soft) reporting or a confirmed reporting done by die TFM 
processor. This may cause the Accounting Agent to reverse the trade in its 
records and to re-book it. 

> The IM can unilaterally replace the accounting-specific data. The TFM 
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processor then releases the replaced message to the Accounting Agent. 
(This will lead the Accounting Agent to reverse the trade in its records and 
to re-book it) 

5 Identification of the Accounting Agent 

Some of allocations will not require additional accounting data, nor will 
there be an Accounting Agent identified for them. For those allocations that 
require accounting data to flow to an Accounting Agent, it is necessary to 
identify the specific Accounting Agent related to the account in the allocation. 
10 There could be more than one Accounting Agent associated with an account 
This can be done either by having the IM maintain such a list in the profile 
(account by account), or by asking the IM to provide the Accounting Agent's 
identifications and deadlines with the allocation. 

The TFM processor timestamps the incoming settlement details message 
IS upon receipt and assign a unique receipt reference number for the setdement 
details. The TFM processor also validates the message for syntax and performs 
the necessary edit checks. If there are any errors detected during the syntax or 
edit checks or context validation, the TFM processor sends an error message 
indicating the reasons for error to the sender of the message. 
20 If the validation is successful, the settlement details are accepted and the TFM 
processor proceeds to match the settlement details if the corresponding 
settlement details have been provided by the counterpart. 

Matching Process 

25 The matching block will be used to compare the settlement details at an 
allocation level; otherwise the following fields must be used for matching: 

> Trade Match Reference Number 

> Allocation Sequence Number 
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> IM Client Account Number 

> Allocation Quantity 

> Security identification 

> Settlement Date 

5 > Settlement Currency 

> Method of settlement 



If the above comparisons result in an exact match, then the TFM processor 
performs the comparison of the settlement location details provided by the B/D 
10 and the GC. 



> If the B/D and the GC have specified the same settlement location then the 
TFM processor sets the status of the allocation as settlement channel 
compatible, provided that the settlement details confirm to the settlement 
15 location characteristics (e.g., DVP in France against Euro is valid; not 
against USD). Further, if the Agents at the settlement locations are the 
same, the "SAME AGENT" flag is turned on. This informs the participants 
that the settlement may happen in the books of the same local agent at the 
settlement location. 

20 



> If the settlement location is not the same, the TFM processor performs a 
compatibility check for a possible Bridge Link between the locations for the 
settlement currency and security categories by referencing the TFM 
25 processor's settlement bridge table and the profiles of both the B/D and the 
GC. 

The following information is. maintained for the Settlement Channel 
Compatibility in the TFM processor. 

30 
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> Other Compatible Settlement Locations (Settlement Bridges) 

> For each bridge: 

5 > Supported settlement currencies 

> Category of the securities supported 

> Securities agent and account details 

> Cash agent and account details 

> Transaction type codes used for the Bridge. Settlement between the 
10 Settlement Locations 

If the settlement channel compatibility is established through a Bridge Link, the 
allocation status is set to Settlement Channel Compatible. 

15 The TFM processor modifies the settlement details as provided by the B/D and 
the GC to reflect the conditions of a particular Bridge Link. These include 
modification of the following details: 

> Addition of Bridge Securities Agent details 
20 > Addition of Bridge Cash Agent Details 

> Addition of Transaction Code for the Bridge settlement 

If there is no bridge settlement channel compatibility between the settlement 
locations for the settlement currency and security category, then the allocation 
25 status is set as Settlement Channel Incompatible. The B/D and the GC may 
change the settlement location appropriately to make the settlement channel 
compatible. 

In certain markets, the B/Ds may need the settlement details from the GC 
30 before they can submit their part of the settlement details. B/Ds in their profile 



65 



WO 03/D652S* PCT/GB02/00463 

will specify for each settlement location whether they need the settlement 
details of the GC before they can submit their settlement details. 



If the B/Ds have set-up their profiles to indicate that the TFM processor need to 
5 send them the GC settlement details once the settlement details are received 
from the GC, the TFM processor will "push" a message to the B/D with the 
details of GC Settlement Details. 

Example: 

10 

The B/D sells a French bond and wants to deliver from its Euroclear account 
6789. 

The Settlement Location is Euroclear. 

15 The settlement details from the B/D will indicate: 
DVP 

Euroclear (location) 
Euroclear (agent) 
Account 6789 

20 

The GC wants to receive securities in its account ABCD at Paribas. The trade 
is for the benefit of client account 1234 at the GC indicated in the allocation. 

The Settlement details from the GC will be: 
25 DVP 
France 
Paribas 

Account ABCD 

30 The Bridge table confirms that this transaction in Euros can be conducted 
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through the Bridge from Euroclear to France, using the Euroclear 
correspondent in France (Societe Generate). 

Account XYZ of Euroclear at Societe Generate for cash and securities. 

5 As a result of this, an instruction will have to be sent by the GC in the SWIFT 
format that includes the following information about Bridge details: 

Receive 

From Societe Generate 
10 . Account XYZ 

By order of 6789 at Euroclear 
French Bond 
Against XXXXEuros 
In favor of 1234 at GC 

15 

The B/D will send instructions to Euroclear as follows: 

Deliver 
To Paribas 
20 Account ABCD 

In Favor of 1234 atGC 

French Bond 

Against xxx Euros 

By order of 6789 at Euroclear 

25 

As can be seen, the settlement details of the B/Ds AND information from the 
bridge table were used to construct these messages. 

In the case of DSP trades, the TFM processor will generate only the securities 
30 movement instructions and not the cash movement instructions. In the case of 
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FOP trades, TFM processor will generate only securities movement 
instructions. 

5 Out put 

The following are the outputs from this business function. The message is 
routed to the appropriate participant access module (participant AM) based on 
the routing profile set by the participant If the substituting party has submitted 
the message, then the message is sent to the substituting party. 

10 

> Success message: is sent, along with the settlement details received by the 
TFM processor, if the participant has specified in the profile that they wish 
to receive these messages. 

15 

> An Error message: indicating the reasons for validation failure, is sent if 
there are any validation failures, along with the settlement details received 
by the TFM processor. 

20 > GC Settlement Details: is sent to the B/D, if the B/D has indicated in its 
profile that it needs the GC Settlement details prior to submitting its 
settlement details. 

> Settlement Match Notification: if settlement details match, a message is 
25 sent to both the GC and the B/D. Any match warnings and changes to the 

settlement details on account of bridge settlement are also notified to the 
participants along with the match notification message. 

> Settlement Release Details: a notification message is sent to the B/D and 
30 the GC with settlement release details. 
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> If all the allocations of the block trade settlement details have matched, the 
TFM processor sends a status change notification to the B/D and the IM 
stating that all the allocations settlement details have matched. 

5 

Settlement Match Notification 

10 If settlement channel compatibility is achieved, the following notification 
message is sent to the GC and the B/D 

> Trade Match Reference # 

> Trade Reference U 
15 > Trade Version # 

> Allocation Sequence # 

> Allocation Version # 

> Settlement Details Version U 

> IM Client Account # 
20 > Allocation Quantity 

> Settlement Details 

> Identification of the clearing organisation 

> Settlement Currency 

> Settlement Location of GC 
25 > Settlement Location of B/D 

> Settlement Type Flag (FOP or D VP) L 

> Same Agent Flag 

> Local Agent Details of the B/D 
30 > Security Agent at Location 
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> Local agent identification with the clearing organisation 

> Securities Account at Agent 

> Cash Agent at Location 

> Cash Account at Agent 

5 

> Local Custodian details of the GC 

> Security Agent at Location 

> Local agent identification with the clearing organisation 
10 > Securities Account at Agent 

> Cash Agent at Location 

> Cash Account at Agent 

> Transaction Code to indicate Bridge Settlement 
15 > Warning Field 

> Warning Code 

Segment Release Petails 

20 

The TFM processor sends a notification message for the settlement release 
details at an allocation level to the GC and to the B/D. This message will be 
sent once the Allocation has been matched for bo th the settlement details ami 
Net Proceeds Details. 

25 

The Settlement Release message provides the following details. 

> Trade Match Reference # 

> Trade Reference # 

> Trade Version # 

30 > Allocation Sequence # 
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> Allocation Version # 

> Settlement Details Version # 

> IM Client Account Number 

> Security Identification 

5 > Trade Price (Seller's Price) 

> Allocated Quantity 

> Trade Date 

> Settlement Date 

10 > Settlement Details 

> Identification of the clearing organisation 

> Settlement Currency 

> Settlement Location of the GC 

> Settlement Location of the B/D 
15 > Physical Address 

> Transaction code if there is a Bridge Settlement 

> Settlement Type Flag (FOP, DSP or DVP) 

> SAME AGENT flag 

> Free flow information 

20 

> Prevailing party's Settlement Amount details (if net proceeds match within 
tolerance) or IM's Settlement Amount details 

> Gross Amount 

> Net Amount 

25 > Components of the Net amounts 

> Difference between the IM*s amount and the B/D's amount 

> Local Agent Details of the B/D . 

> Security Agent at Location 

30 > Local Agent identification with the clearing organisation 
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Securities Account at Agent 
Cash Agent at Location 
Cash Account at Agent 



> 
> 
> 
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5 > Local Custodian details of the GC 

> Security Agent at Location 

> Local Agent identification with the clearing organisation 

> Securities Account at Agent 

> Cash Agent at Location 
10 > Cash Account at Agent 

Note - These outputs will be adapted to reflect the bridge information 

Variations 
15 Broker-to-Broker Trade 

In Broker-to-Broker trades there will be no allocations. Both B/Ds can also 
provide the Settlement details as part of the NOE message or through a 
separate message. There is no specific process change. 

20 Ftmfl-fr-Fwd Trade 

The Fund-to-Fund trade is reported to the TFM processor as two independent 
trades that can be linked with a common link number. Two legs of these trades 
are settled via the intermediate counterpart. No process change is envisaged for 
25 settlement details processing. 
6. Forex Processing 

EMs carry out Forex (Foreign Exchange) Processing on behalf of their 
clients to handle either the setdement required for the security trades or 
independent of any security trades. Even though the TFM processor will not 
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support Forex trades for regular processing, like Block Trade, Allocations, etc., 
this information needs to flow to the GC and Accounting Agent for information 
and action. 

5 TFM processor Functionality 

The TFM processor will receive a free-flow Forex message from the IM. This • 
message will have the necessary details about the Forex carried out by the IM, 
the clients on whose behalf the Forex has been carried out and if necessary any • 
associated security transaction reference numbers. The information supplied by 

10 the IM will be similar to the MT 304 message format. The format has been 
adjusted for the TFM processor requirements. 

IMs will be able to send the spot and the forward Forex contracts to the 
TFM processor. For the forward contracts participants will need to submit the 
opening, partial closing (if any) and final closing of the forward contracts as 

15 separate trades with unique Forex trade reference numbers. The IM must 
always provide complete information in the opening and closing of Forex 
contracts. The TFM processor will not carry out any validations between the 
opening and closing contracts and will not cany forward any information 
between the opening and the closing Forex trades. 
20 The information supplied by the IM will be sent to the GC and the 

Accounting Agent associated with the Client. 

Enppt Information 

25 The following is the information provided by the IM to inform the TFM 
processor about Forex information. 

The following table describes the information provided by the IM: 



30 FIG. 42 
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The TFM processor will validate the input message for content and format On 
successful acceptance of the Forex trade message, the TFM processor will send 
a similar Forex trade notification message to the GC and the Accounting Agent 
5 identified for each allocation in the message. 

The outputs to the GC and the Accounting Agent will be at the level of each 
individual allocation of the Forex trade. 

10 Outputs 

The following are the output from this process: 

> A success message to the IM indicating that the Forex trade has been 
15 accepted by the TFM processor 

> An Error message to the IM for each Forex trade allocation that fails 
validations 

20 > A Forex notification message to the GC and the Accounting agent for each 
allocation associated with the Forex trade. 

7. Cancellations. Replacement ™H Deletion Processing 
25 Principles 

• A transaction should only be cancelled as a last resort because: 

- This will create extra work for everyone who has worked on the 
trade to re-instate their information on a new transaction 

- Creating a new transaction with a new participant trade reference 
JO number would break the audit trail and limit the value of the MIS 

7* 
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provided by the TFM processor (e.g., all rimers would be reset). 
This is true even at the NOE / BON level where there may be price 
or commission changes which do not invalidate the entire 
* transaction 

5 • The normal process for agreeing changes to matched trades will rest 
outside of the TFM processor with only the final results flowing through 
(i.e., in most cases telephone conversations are required to negotiate a 
change) 

• Non-matching fields are as significant as matching fields since they are 
10 only included in the TFM processor so that they can be communicated 

between parties for subsequent action 

• All changes to a message (replacement, deletion and cancellation) will be 
immediately communicated by the TFM processor to all parties who 
received the original message 

15 • The functionality of the TFM processor should not be driven or 
constrained by the systems capabilities or working practices of the 
participants 

• Only the originating party of a message should be able to change it 
20 Options 

The IM or B/D can cancel a trade, which terminates the transaction 
history in the TFM processor. Data is resubmitted with a new participant trade 
reference number. This function is used when a trade was created in error or 
when a trade has matched with the wrong counterpart and needs to be re- 
25 entered with the correct counteipart. However, all participants may not have 
the capability in their internal application systems to effect a replace when only 
some of the particulars of the trades need to be modified. Some participant may 
also use cancellation and resubmission to correct any mismatches. These 
participants' internal application systems will generate a cancellation and 
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resubmission to effect the modification, fin such cases, to support participants in 
tracking MIS, the TFM processor will allow the participants to link new trades 
to an existing cancelled trade* The TFM processor will inform counter parties 
and GC about the linked cancelled trade reference number. This will allow 
5 participants to keep track of the cancellation and the resubmission of the trades. 

The IM, the B/D or the GC can delete a single message they have sent at 
the level of an individual allocation. This option applies to all allocation level 
messages (Allocations, Net Proceeds and Settlement Details) and removes the 
message leaving all others intact and maintains the audit trail in terms of the 
10 participant trade reference number. However, deletion of allocations will 
cascade to Net Proceeds and Settlement Details as well. 

The EM, the B/D or the GC can replace a single message they have sent 
with an entire new message. This option applies to all messages (NOE, BON, 
Allocations, Net Proceeds, Settlement Details, etc.) and changes one message 

15 at the level of an individual allocation leaving all others intact and maintains 
the audit trail in terms of the participant trade reference number. In this case 
the entire message is replaced with a new one (This function will not support 
changing a single field within an allocation although clearly users will edit ' 
single fields on their workstation before resubmitting entire messages.) 

20 Finally, participants might need to revoke a requested cancellation when it has 
not taken effect and is awaiting a corresponding cancel from counterpart. This 
revoke can only be used when approval is pending from counterpart. 

Approvals and Paired Vs. Matched 
25 The cancellation of a trade requires approval after the trade has been 

/•Matched." The submission of the cancellation request by the counterpart will 
be treated as the approval of the cancellation request. If participants mistakenly 
cancel the wrong trade, they will have the provision to revoke their 
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cancellation. 

For replacement or deletion, there will be no special approval messages 
supported by the TFM processor. The party making a change will submit the 
replacement message that the TFM processor will attempt to match with the 

5 existing counterpart's message. If a match does not occur, the TFM processor 
will move the trade or the allocation to a "paired" status. When "paired,'' if the 
counterpart submits a matching replace/delete message men the new values 
will be deemed to have been 'approved' and the new messages will update the 
TFM processor. The trade or the allocation will now change from "paired" 

3 status to "matched" status. AH alert and deadline processing will continue to 
apply for a paired trade. 



If the block trade is paired, subsequent matches will not be attempted by 
the TFM processor. For example, if the Block Trade is paired due to a price 
15 change, new net proceeds submitted by the participants on the paired trade will 
not be matched. This match will be triggered once the block trade becomes 
matched (Le., due to a matching replace from the counteipart). 

Cancellation of Tr»r?P 

20 The IM and the B/D can cancel the Trade at any time during the life cycle 
of the trade. However, a cancellation request needs an approval from the 
counterpart, if the trade has been matched. 

• The format of the cancel message will have the complete format of the 
NOE or BON message with function of the message as "CANC" and will 

25 trigger a cancellation. 

• The cancellation of an unmatched trade becomes effective immediately 
with no approval needed from the counterpart. 

• In the Matched Trade Status, the cancellation submitted by one party needs 
30 to be approved by the counterpart The intermediate status of the trade will 
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be "Matched Cancellation Requested" and will be set to "Cancelled" only 
when approved The second cancel trade message submitted by the 
counterpart is treated as an approval to the first cancel trade message and 
the trade status is set to "Cancelled. 4 * 
5 • The details of the trade submitted as part of the Cancel Trade will be 
compared with the existing trade details to validate the integrity of the 
Cancel. 

■ All GCs and the interested parties pertaining to the allocations of the trade 
are notified of both cancellations requested by IMs and the Cancellation of 
10 the trade by the TFM processor after approval by the B/D. The GC and the 
Interested Parties will not be notified of any cancellations requested by the 
B/D. However, the GC and the Interested Parties will be notified of the 
cancellation of the trade after the IM approves the cancellation. 

• The Cancellation status of the trade flows to the individual allocations. 

15 

Additional Features; 

• Revoke a Cancellation: A cancellation submitted by a party can be 
revoked by the same party by using "REVC" in the function of the Trade 
Message (NOE or BON). The revoke will be effective only when the 

20 approval is pending (Trade status = "Matched Cancellation Requested") and 
not after actual cancellation has taken place. If a cancellation is revoked all 
the participants who have received prior information about the trade and its 
allocations will also be informed about the revocation of the cancellation 
request 

25 

• Reject an unmatched alleged trade: Cancellation of Unmatched trades 
which are alleged against a participant can be done by using "REJM** in the 
function of the Trade Message, A Trade in this state is "Rejected." The 
final cancellation of the trade will be after an approval via a cancellation 

30 message from the participant alleging the trade. This will be used for the 
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DKs. Similar to a revoke of a cancellation, the rejection of an alleged trade 
can also be revoked by the party submitting the rejection against the 
unmatched alleged trades. 

5 • Dispute an unmatched alleged trade: Dispute of Unmatched trades which 
are alleged against a participant can be done by using M REJM" in the 
function of the Trade Message. In addition to this the disputing participant 
can provide a reference to one of their unmatched trades indicating that the 
alleged trade should match against this unmatched trade, 

10 

If the IM has requested cancellation, downstream processing of the TFM 
processor will be effected by way of output messages generated from the TFM 
processor. Accounting information and settlement release will NOT be sent 
once the IM has requested for cancellation. The remainder of the outbound 
15 messages will always contain the Trade/allocation status. The revoking of 
cancellation will resend the accounting information to the accounting agent. 

The following diagrams explains the various cancellation possibilities and their 
associated message flows: 

20 

Case 1: 

A B/D wants to cancel a trade that has not been matched In this case the B/D 
has submitted an NOE to the TFM processor (1). The TFM processor has 
accepted the NOE and has created a trade in an "unmatched" status. (2), The 

25 TFM processor has also sent an Alleged NOE notification to the IM (3). Before 
the IM submits a BON, the B/D realises that the trade is a wrong trade and 
issues a cancellation (4). The TFM processor immediately cancels the trade as 
it is in 'Unmatched" status and sends a cancelled notification to the B/D (5) 
and an alleged trade cancelled notification to the IM. FIG. 43 illustrates the 

30 flow of information for case 1 . 
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Case 2: 

An IM wants to cancel a trade that is matched and for which allocations are 
complete. If the B/D were to initiate the cancellation, the GC will not be 
5 notified of the cancellation request. Similarly if any interested parties like 
accounting agents have received information prior to the cancellation, then the 
TFM processor will treat them similarly to the GC as illustrated in the diagram. 
FIG. 44 illustrates the flow of information for case 2. 

10 Case 3: 

The B/D has submitted an NOE against the wrong IM. The IM DKs the NOE. 
The B/D cancels the NOE. FIG. 45 illustrates the flow of information for case 
3. 

IS Case 4 

The B/D has submitted an NOE with the wrong price. The IM submits a BON 
with the right price. The IM submits a dispute message against the NOE 
indicating the reference # of the BON. FIG. 46 illustrates the flow of 
information for case 4. 

20 

Replace Process 

The replacement of an individual message will be effective immediately if the 
message has not been matched. A Replace of an NOE or a BON is possible on 

25 an unmatched trade. Similarly, Replace of Allocations is effective immediately 
if it has not matched on the Net Proceeds or the Settlement Details. A Replace 
on a matched trade will move the trade into "Paired" status if the replacement 
message does not match. A Replace on an allocation that is "NP Matched" will 
move the allocation into "NP Paired." A Replace on an allocation that is 

30 "Settlement Details Compatible" will move the allocation into "Settlement" 
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Details Paired" status. The principle of the replace on the matches at several 
levels is to retain their matched status or an intermediate status of <c Paired. " 

Replace NOE/BON 
S A Replace on an unmatched trade will be effective immediately. If the 

TFM processor has sent a notice of pending transaction for the unmatched trade 
the TFM processor will also send an alleged trade replace notification to the 
counterpart to indicate the replacement. 

A Replace on a matched trade will move the trade into 'Taired 4 * status if 
10 the new message does not match, otherwise it will remain in matched status. 
The 4 Taired w status is indicative that a previously matched trade is now being 
replaced and should not be matched with a different trade (e.g., if the BON is 
replaced it should only be matched against the original NOE with which it was 
paired). Similarly the original NOE should not be paired with a different BON. 

15 

Hie following elements of a trade should not be replaced after a match: 

• Physical Sender Identification 

• Message Type 

• Actual Sender Identification 

20 • Participant Trade Reference Number 

• External Common Reference 

• Function of Message 

• Transaction Type 

• Processing Type 

25 • Counterpart Identification 

• Buy/Sell Indicator 



If any of the above elements change after a match, the participant can cancel 
the trade and resubmit a new trade. 
30 The TFM processor implements procedures to ascertain the integrity of 
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the information that it accepts. For example, Replacement of the Trade 
Quantity on an NOE or BON is always checked against the sum of the 
allocation quantity if the allocations have arrived. For a partially allocated 
trade, the sum of the allocated quantity so far is less than the replaced/revised 
5 block quantity. For a completely allocated trade, the sum of the allocated 
quantity should be equal to the replaced/revised block quantity. Similarly, the 
TFM processor also recalculates the deadlines if any of the parameters* 
affecting the deadlines (e.g., preferred setdemeht location) is changed. 

The TFM processor will notify all the participants who have received 
10 information about the BON or the NOE about any replacements. Normally the 
replacements made by only the IM will be sent to the GCs and the Interested 
parties. However, if the B/D replaces the settlement location in the NOE, then 
the GC will be notified of the new settlement location. 

15 The following cases illustrate various replacement scenarios for NOE and BON 
messages. 

Case 1: 

The B/D submits an NOE with the wrong price. The trade has not been 
20 matched with a BON. The B/D submits a replace 1o correct the price. 
Information flow for this scenario is shown in FIG. 47. 

Case 2: 

In this case the B/D has submitted an NOE with price of USD 75.00. The IM 
25 has also submitted a BON with price of USD 75.00. After the NOE and the 
BON have matched, the IM wants to renegotiate the price as USD 74.00. 
Information flow for this scenario is shown in FIG. 48. 

30 Replace Allocations 
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The IM can replace the allocations. When the replace/delete is effective, 
deadlines at the allocation level are either reset in the case of a delete or 
recomputed in the case of a replace. If the deletion of Allocations changes the 
trade from fully allocated to partially allocated, then the deadlines at the level 
5 of the trade for the Allocation completion are re-instated. 

If the allocation quantity has changed, the sum of the allocation quantity 
will need to be verified to determine if it is less than or equal to the block 
quantity. If net proceeds messages have already been received for any of the 
allocations the quantities and account numbers must be checked against the 
10 new allocation message to ensure that they are consistent If not, the status on 
that allocation must be moved to paired. This indicates that although the net 
proceeds messages may agree with each other, they do not match the revised 
overall allocation from the IM. 

If the GC is changed and a Settlement Details message has already been 
1 5 received from the original GC, the message will be deleted and the status of the 
allocation changed to "Settlement Details Unmatched." 

Replacements of other fields in the allocation will only flow as 
notifications to the GC and the B/D or the IM and will not affect trade status. 
Notification of Allocation Details replacement will flow to the B/D and the 
20 GC. If the GC changes, the new GC is also notified. 

Replace Wet Prncnff Settlement n»r,»l« 

• The IM or the B/D can replace Net Proceeds. 

• The B/D or the GC can replace Settlement Details. 

25 • Originating Party of the Net Proceeds/Settlement Details message can 
replace its part of the message and the replacement will be effective 
immediately, if Net Proceeds/Settlement Details have not yet matched with 
the counterparts. 

• The TFM processor will receive the first Replace Net Proceeds/Settlement 
3D Details message and store the replacement request of Net 

83 



WO 03/1)65256 PCIYGB02/0O463 

Proceeds/Settlement Details and will notify the counterpart. 

• If flie allocation message was matched, the allocation will be put to "Net 
Proceeds Paired" or "Settlement Details Paired** status if the new message 
does not result in a match. Otherwise it remains in matched status. The GC 

5 receives notification of the net proceeds status change. 

• If the allocation status is paired, when the TFM processor receives the 
second Replace Net Proceeds/Settlement Details message it stores the 
replacement request of Net Proceeds/Settlement Details from this party and 
the TFM processor attempts a rematch on the replacement messages. 

10 • If rematch of both replacement messages is successful (exact match, no 
tolerances and no bridges), the TFM processor will notify both parties and 
set the allocation status to "Net Proceeds Matched" or "Settlement Details 
Compatible/* If the Net Proceeds matched, the GC will also receive a 
notification message of the replacement 

15 • No Settlement Release will happen on an allocation that is "Settlement 
Details Paired" or "Net Proceeds Paired.** 

• No confirmed accounting Information will be sent for an allocation that is 
"Net Proceeds Paired" 

20 The Deleting Process 

Deleting Allocations 

Deletion of individual allocations by the allocating party is unilateral 
and requires no approval, irrespective of the status of the allocation. Deletion of 
25 an allocation delete the corresponding Net Proceeds and Settlement Details. 
All parties are notified of the deletion. This option is to be used when the 
block trade quantity changes or an allocation is invalid and has to be removed 
The approval process has been- kept outside the TFM processor, as 
resubmission of net proceeds and settlement details is mandatory for further 

• 

30 process flow. 
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Deleting Net Proceeds/ Settlement Details 

Deletion of a Net Proceeds or Settlement Details in an unmatched state 
is effective immediately. Deletion of a Net Proceeds/Settlement Details , 
5 message that has matched moves the allocation to "Unmatched Net 
Proceeds/Settlement Details" status. The counterpart and the GC (in the case 
of NP) are notified of the change. Also, the settlement release and the 
accounting information will not be generated from the TFM processor. 

10 Messaging impacts due to cancellation/deletion/replacement process 

The following are the general principles followed within the TFM processor 
to notify the counterparts, the GCs and the interested parties about any 
cancellations, deletions and replacements. 

> For unmatched alleged trades (after the TFM processor has sent out the 
15 Notice of Pending Transaction), counterparts will receive all the 

cancellations, the deletions and the replacements. 

> For matched trades, counter parties will receive all the cancellations, the 
deletions and the replacements so that they can provide the necessary 
approval. 

20 > Counterparts will receive the cancelled, the deleted, the replaced (via a 
match) notifications once the TFM processor has accepted and processed 
the necessary approval. 

> The GCs and the Interested Parties (Accounting Agents) who have been 
notified of the trade and allocation information will receive the 

25 cancellations, the deletions and the replacements carried out by the IM. 
They will not receive the notification pertaining to the cancellation, 
deletions and replacements carried out by the B/D, They will receive two 
when the IM initiates the cancellation or replacement and when the B/D 
approves the cancellation or the replacement. They will also receive a 

30 revoke notification, if the IM decides to revoke their cancellation. 
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> GCs who have been notified of settlement instructions in the 52x, 53x or 
54x SWIFT mess&gc formats may be sent a cancellation message in the 
form of MT592 if either the trade is cancelled, (i.e., cancellation initiated by 
IM or B/D and approved by the counterpart), or when the allocations are 
5 deleted by the IM. If there is a replacement of any details pertaining to 
settlement details such as Net Proceeds, the TFM processor will generate a 
cancellation in the MT592 SWIFT message format followed by a settlement 
instruction with the changed details in the 52x, 53x or 54x SWIFT message 
formats. 



10 
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Alert and Deadline Processing 

Alert and Deadline processing in the TFM processor occurs with respect to 
two distinct processes: 
5 • Settlement 
• Accounting 

The alert and deadline process responds (and also escalates, if necessary) to 
meet the earliest timing requirements of both the settlement and the accounting 
processes. This is true in cases where the information is required for both 
10 processes. If information is required for one of the processes only (e.g., net 
proceeds are required for both settlement and accounting, settlement details are 
required for settlement only), then the related deadline applies. In this manner, 
the alert and deadline process establishes the critical path for the submission of 
all data in the TFM processor. 

15 Settlement 

Alert and deadline processing related to settlement must meet the 
requirements of the GC and the B/D (or B/D's Agent) in the context of the 
settlement location involved. Therefore, settlement date and deadline time 
established by setdement location will serve as the foundation for the alert and 
20 deadline process in terms of settlement. 

The Deadlines and the associated alerts should be based on settlement 
date/deadline time minus an amount of time specified by the GC and the B/D in 
their profiles. The GCs and the B/Ds will also maintain deadlines for cash' 
settlement if the trades are to be settled separately for cash and securities (DSP 
25 method of settlement). The deadlines for the cash settlement will be based on 
setdement date^deadline time minus an amount of time specified by the GC and 
the B/D in their profiles. 

The larger of the amounts of time (i.e., earliest time computed after 
reducing the amounts of time specified by the B/D and the GC from the 
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settlement date/deadline time) specified by the GC and the B/D (for both cash 
and securities) will be used. If this profile information is not available for the 
GC and the B/D, the system default for the given market will be applied. The 
deadline for the settlement related information could be expressed by the 
5 following formula: 

Deadline = Market Settlement Date/Deadline Time - GC or B/D or Generic 
Specified Amount of Time (for cash and securities settlement) 

Market settlement Date/Deadline Time will be based on the settlement 
currency, instrument type and method of settlement. For example, the Great 

10 Britain Market could have different deadlines for settlement currency GBP and 
USD, different deadlines for equities and fixed income instruments and 
different deadlines for delivery versus payment and delivery free of payment 
method of settlement. The deadline in the Great Britain Market for GBP 
settlement for equities and for delivery versus payment can be 2:00 PM local 

15 time on every settlement date. 

The amount of time specified by the GC and the B/D in their profiles 
will initially be based on settlement location. The TFM processor will be 
designed with the flexibility to specify the amount of time prior to the 
settlement date/time by settlement currency, instrument type and method of 
20 payment 

Even though the alert processing within the TFM processor is based on 
the earlier of the deadlines set by the B/D or the GC, the TFM processor for 
MIS reporting to the IM will also track the GC deadlines (i.e., whether the IM 
has missed the GCs deadline or not). It is logical that the alerts for settlement 
25 related processes follow the most likely sequence of participant message 
submission. For example, alerts regarding net proceeds should be triggered 
prior to alerts relating to settlement details for a given trade. 

Participants may specify the deadline timings in UTC (formerly GMT). 
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Accounting 

The deadline for the submission of the information required for 
5 accounting purposes will be based on trade date/time or Allocation Date/Time 
plus an amount of time specified by the Accounting Agent in its profile. The 
deadline for accounting puiposes can be expressed by the following fonnula: 

Deadline = Trpde Date/Time or Allocation Date/Time + amount of time 
10 specified bv Accounting A ? »nt 

The deadline specified by the Accounting Agent will be used by the 
TFM processor to carry out any unconfirmed (soft) reporting, if required, for 
the Trades and Allocations. Confirmed reporting by the TFM processor will be 

15 initiated once all the infonnation required for Accounting has been submitted 
and matched. Confirmed reporting will not be based on any deadline 
processing. Confinned reporting will be done by the TFM processor as soon all 
the accounting details are available and the Net Proceeds are matched. It is not 
envisaged at this point to have the need for two separate deadlines for 

20 unconfirmed reporting and confirmed reporting. It is likely that Accounting 
Agents will specify different amounts of time for different categories of 
accounts. For example, the amount of time specified for a mutual fund that 
requires a daily net asset value (NAV) calculation will likely be shorter than 
mat specified for a pension fund with monthly valuation. 

25 Accounting deadlines can also be specified at time of the trade date, 

time of the trade date plus a number of days, time of the week and time of the 
month for unconfirmed reporting. Accounting Agents will also specify the 
reporting period required in the case of non-standard reporting such as time of 
the week, etc. For example, an Accounting Agent can specify for an insurance 

0 fund registered in Australia a weekly reporting at 5:00 PM Australian Time on 
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Friday for all trades submitted from the last Friday to the previous Thursday. 

Participants will specify the deadline timings in UTC (formerly GMT). 

IMs should understand the accounting implications for the different 
account categories associated with their clients- IMs will need to specify the 
5 Class of Account for each of their clients either at the level of the trade or at the 
level of account in their profiles. 

The location of the Accounting Agent will also be taken into 
consideration. The system will perform escalations based on the time zone of 
the Accounting Agent. If an Accounting Agent has operations in multiple time 
10 zones, the identification of the accounting agent will have to recognize that fact 
through the use of an 1 1- character BIC It is possible that in some cases, Trade 
and Allocation details will be sent to the Accounting Agent prior to the 
completion of the matching process (Soft Reporting). 

15 Alert and Deadline Processing 

Trades are monitored throughout the states of the trade life cycle from the 
input of the first information typically an NOE or BON, through to the 
Settlement Channel match. Completion of the following different events are 
monitored: 

20 • NOE/BON Match 

• Completion of Allocation 

• Net Proceeds Match for each Allocation 

• Submission of Accounting Information for each Allocation (Accounting 
Information will be submitted along with Tegular messages such as 

25 BON, NOE, Allocations and Net Proceeds). 

• Settlement Channel Match for each Allocation 

When deadlines are established in the TFM processor, the trade record will be 
updated with the deadlines. The trade will have a timer field, which contains 
the deadlines for each event. These deadlines will be visible to the user in the 
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any of the following ways: 

• 'Whenever trade details are queried 

• Available in any message/pending transactions sfent fc^tfte TV j# • \ " 
processor . 

5 

Warnings will be flagged against the trade if any of ^4mm^'^^ 
for the trade. 

Individual deadlines are explained below: 

NOE/BON Match 

10 If the trade is input on Trade date, the deadline for th'^#^ 

will be XXX minutes (XXX is a system parameter which fe^^tftJ^ni; bti &b 
type of instrument) from the time of the first transaction ft^t^^'h©.B-.« 
BON). A warning will be sent to both parties of the trade if k m)itcti does apt 
take place within XXX minutes before the deadline. Thfs \Varmtig will be 

15 based on a system parameter as opposed to the profiles of the piiticiparits . 
involved If the trade is input after the trade date, the; wnioii% : Will* sent 
immediately upon successful validation. 



Completion of Allocations 
20 The deadline for completion of allocations will be X^ w^ 

XXX is a system parameter depending on the type of in^utentj arffer th£ 
NOE/BON match. A warning will be recorded in the tmbe ^y fecomptefe 
or missing allocations not presented by the IM's within the dfiadf im:! -; 

Net Proceeds Match 
25 The deadline for Net Proceeds match will be based 6n £r<tfi1e of the 
GC, the Accounting Agent and the B/D. The deadline fori tirt^(*eedsj 
match and the associated alerts should be based on the edrlie^;%the aodounting- 
and the settlement deadline as expressed above. 
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The settlement location is based on the following information: 

• Settlement Location specified by the B/D in the NOE 

• Instrument Code data (country of issue) in the absence of any settlement 
location information 

5 • Settlement Location, if and when specified by the GC 

In the absence of deadlines based on the information in the profile of the GC, 
the Accounting Agent and the B/D, the generic TFM processor deadlines, as 
given below will be applied. 
10 The deadline for Net Proceeds match will be defined as XX 

hours/minutes prior to the Settlement Date/Deadline Time. The parameters, 
XX hours/minutes will be based on the deadlines for the settlement location 
and could be different for different types of instruments. A warning will be 
sent to both parties of the trade if a match does not take place within XXX 
15 minutes before the deadline. This warning will be based on a system parameter 
as opposed to the profiles of the participants involved 

Submission of Accounting Information 

The deadline for the submission of information required for additional 
accounting purposes will be based on trade date/time or Allocation Date/Time 
plus an amount of time specified by the Accounting Agent in its profile. 

Warnings will be sent "pushed" to the IM and the B/D if the requirements for 
accounting are not completed by XX hours/minutes before the accounting 
deadline where XX is a parameter maintained by the IM in die profile. This 
explained below: 

• The IM will receive notifications that allocations relating to a block trade 
have not been received by the TFM processor. This notification process 
will be based on a default amount of time, for example at the end of the day, 
unless a specific parameter is established in the IM's profile. 

♦ The IM will receive a warning if the accounting information is not input 
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XX hours prior to accounting deadline 

• Warnings will need to be sent to the Accounting Agent in cases where the 
accounting information is released prior to the completion of the net 
proceeds matching process clearly indicating that the reporting is a 
5 unconfirmed reporting. 

Settlement Channel Match 

The deadline for settlement channel match will be based on the profile 
of the GC and the B/D. The deadline for the settlement channel match and the 
associated alerts should be based on the settlement date/Deadline time in the 
10 relevant settlement location minus the larger of the amount of time specified by 
the GC and the B/D in their profiles. 

The settlement location is based on the following information: 

• Settlement Location is specified by the B/D in the NOE 

• Instrument Code data (country of issue) in the absence of any settlement 
15 location information 

• Settlement Location if and when specified by the GC 

In the absence of deadlines based on information in the profile of the GC and 
the B/D, generic TFM processor deadlines, as given below, will be applied. 

The deadline for the settlement channel match will be defined as XX 

20 bours/mlnu tes prior to the Settlement Date/Deadline Time. The parameter 
XX hours/minutes will be based on the deadlines for the settlement location 
and could be different for different types of Instruments. A warning will be 
sent to both parties of the trade if a match does not take place within XXX 
minutes before the deadline* This warning will be based on a system parameter 

25 as opposed to the profiles of the participants involved. 

Setting of Deadlines 

All of the above deadlines will be calculated and the earliest of the 
deadlines will be set. For example, if a trade is input on settlement date (i.e., 
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trade date is the same as settlement date) at 13:00 UTC, then the deadline for 
NOE-BON match is calculated by the TFM processor as 15:00 UTC (+2 hours 
from trade input). The TFM processor also finds that settlement deadline for 
the trade is 14:00 UTC. Since the settlement deadline is earlier than the NOE- 
5 BON match deadline as calculated by the TFM processor, The TFM processor 
sets the NOE-BON match deadline as 14:00 UTC 

Master and Reference Data 

All generic and specific processes of the TFM processor make use of 
10 data in one form or another. The data can be grouped under two broad 
categories - generic data and process data. Process data is used, manipulated 
and updated by all or specific processes (e.g., Trade Details, Allocation Details, 
Settlement Details, etc.) Generic data is used by most of the processes for 
validation or reference purposes. Generic data in the TFM processor has been 
15 further subdivided into MASTER data, PROFILE data and REFERENCE data. 
Since participants maintain most of the profile data in the TFM processor, it 
has been separately dealt with under Profile Maintenance. The data classified 
under Master data and Reference data are explained in this section. 

20 Master Data 

All data that is administered and maintained by the TFM processor for 
generic processes has been grouped under MASTER data. All processes in the 
TFM processor use this data to validate the inputs and to decide on the flow of 
the respective processes. This data is further subdivided according to usage 
25 and the level at which it is stored and maintained. The tables under which 
Master data is stored are given below. 

> Currency 

> Country 

> Primary Numbering Agency Code Identification 
30 > Settlement Location 
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> Settlement Bridge 

The individual tables and their contents are explained below. 
Currency 

The various currencies used in cross-border trades and related information are 
5 maintained by the TFM processor in the Currency Code Table of FIG. 49. All 
currency-related details are validated against this data. 

Country 

Country codes are used to identify the proposed settlement location 
except in the case of ICSDs where a BIC is used. The various countries 

10 involved in cross border trades and the associated default settlement locations 
are maintained by the TFM processor in the Country Code Table of FIG. 50. 

The proposed settlement location indicated in the Notice of Execution 
by the B/D is the location of their local settlement agent. If such a location is 
the country, then the TFM processor Administrator has to determine to 

15 maintain for every country the default settlement location (i.e., the default 
settlement organisation for the particular Instrument Type) to apply both for the 
tolerance for net proceeds and for the related settlement deadlines of the 
location. 

Tolerances 

20 Tolerance for the Net Proceeds matching can be broadly classified as 

Participant and Market. Participant maintained tolerances are detailed under 
Profiles. Market tolerance for the Net Proceeds match will be maintained in 
the TFM processor at the system level by Settlement Location, Settlement 
Currency and Instrument type. This field is also included in the Settlement 

25 Location table explained below. 

Primary Numbering Agency Code 

The TFM processor maintains the primary numbering agency codes for 
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securities by instrument type and country of issue in the Instrument Type Table 

of nasi. 

Settlement Location 

5 The TFM processor maintains the details of all valid settlement 

locations in the Settlement Location Table of FIG. 52. Settlement currencies 
supported at each settlement location will be referenced to validate the 
settlement currency mentioned for the settlement location in the settlement 
details. The method of settlement will also be validated by the TFM processor 
1 0 by referencing this table. 

Based on the generic deadlines to be followed in the TFM processor for the Net 
Proceeds match and the Settlement Details match, warnings will be attached by 
the TFM processor to the subsequent notification messages or query replies to 
the parties involved. 

15 Settlement Bridges 

An authority (such as the GSTPA) can approve the settlement bridge 
channels that support the DVP. The TFM processor maintains necessary details 
of all GSTPA approved settiement Bridges between the iCSDs and between the 
ICSDs and the CSDs to facilitate the exchange of relevant information to the 

20 local agents for effecting proper settlement. The Settlement Bridge Channels 
Table of FIG, 53 details the information the TFM processor will maintain with 
respect to settlement bridges. New bridges may be formed from time to time. 
The TFM processor Administrator will update the above table with the details 
of such new bridges as and when an authority such as GSTPA approves them 

25 for support within the TFM processor environment. In addition, the 
Participants can maintain in their profiles, the settlement bridges they would 
like to support as well as the currencies they will support in these bridges. 
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Reference Data 

Data administered and maintained by third-party vendors that the TFM 
processor will reference for validations has been grouped under REFERENCE 
5 date. Such data can be referenced by the TFM processor from the third party 
database for generic validation or can be referenced from the earlier referenced 
data held by the TFM processor as Cache in its own database. Data stored in 
the TFM processor database will be continuously refreshed. The TFM 
processor validates a financial instrument by accessing a third party vendor 

10 database as and when a transaction is reported. To maximise performance on 
such validations, it reuses the cache data when the same instrument has to be 
validated again. Similarly, the TFM processor updates the BIC database at 
frequent intervals depending upon the frequency of updates of the BICs 
directory by SWIFT. The sets of data that will be referenced by the TFM 

15 processor will be BICs and Security Identification related data. 
Security Identification 

> Financial Institution Identification (BIC) 

> Account Identification is referenced by the participants directly. In the 
current phase, the TFM processor does not support account identification 

20 cross-referencing* 

Security Identification 

The TFM processor may adopt, for example, ISIN as the preferred 
securities identification code. The TFM processor will then maintain ISIN 
numbers for all types of financial instruments as the Primary Identification 
25 code. The primary identification code will be identified for the Instrument Type 
and country of issue. This is to support such cases where an ISIN is not issued 
(i.e., US dealt MBS, ABS). As it is appropriate to consider the use of other 
well-accepted identification codes as an alternative when ISIN are not readily 
available, the following Numbering Agencies codes will be supported. 
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> SEDOL 

> CUSIP 

> QUIK. 

5 

The TFM processor may be configured to support the aforementioned Primary 
identification codes. 

If incoming data contains the identification in the primary numbering agency 
10 code as the source of the financial instrument code, the TFM processor will 
proceed directly with the validation process by obtaining the related 
information from the third party vendor database and performing the necessary 
validations. If the primary numbering agency code is not used, the TFM 
processor will carry out the following translation process. 

IS 

a. The Translation process may be performed through the use of a third party 
providing a cross-reference database for the source and the instrument 
category- The cross-reference will generate the corresponding Primary 
identification code or ISIN code whenever possible for use in the 

20 validation processes. 

b. Matching/validation will take place based on the primary identification 
codes provided by the B/D and the IM, if they use the same Numbering 
Agencies code (ue., both use ISIN, CUSIP, etc.) For example: If both sides 
want to match on CUSIP and CUSIP happens to be primary identification 

25 code for the instrument type, then the matching will be done on CUSIP, No 
translation is done in this case. 

c. Matching/validation will take place based on the translated primary 
identification codes or ISIN codes if both parties used different numbering 
agency codes. 

30 d. The original numbering agency and identification code will always be 



98 



WO 03/065256 



PCT/GB02/00463 



provided together with the translated code that resulted in the match. 

To avoid the need to access the external database every time for validation and 
translation, the TFM processor will maintain the most recent version of the 
5 ISIN related infonnation in its internal cache. The internal cache will be 
refreshed every day to ensure that it is cuirent 

An indicative lists of elements to be maintained is given below. 

> Primaiy Numbering Agency Code 

> Identification in Primaiy Number Agency code 

10 > Other Numbering Agency code (repeated for each code for which 
translation is available) 

> Identification in the other Numbering Agency Code (repeated for each code 
for which translation is available) 

> End/Maturity Date 

15 The information relating to end/maturity date is used for validation 
purposes. The trade date should be earlier than or the same as the 
end/maturity date. 

Financial Institution Identification (BIC) 

A unique ISO Bank Identifier Code (BIC) will identify financial 
20 Institutions. BICs are an internationally standardised method for identifying 
financial institutions. The BIC is designed to facilitate automatic processing of 
telecommunication messages in banking and related financial environments* 
A BIC is either a: 

> SWIFT BIC - a registered BIC of a financial institution connected to 
25 SWIFT or 

> Non-SWIFT BIC - a BIC of a financial institution that is not connected to 
SWIFT (it is denoted by the digit T in the eighth position) 

The ISO Bank Identifier Code (BIC) consists of 1 1 characters, including the 
following four components explained in the Bank Code Table of FIG. 54. The 
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first three components; The Bank Code, the Country Code and the Location 
Code are mandatory components of a BIC. 

Parties interacting with the TFM processor will identify themselves with 
their 8-character or 1 1-character BIC. The GSTPA recommends use of separate 
5 BICs for every role performed by a participating legal entity. The validation of 
this BIC will be done by the TFM processor by referencing the BIC table 
maintained by the TFM processor. The TFM processor will make use of only 
the first 8 characters of the BIC for the puipose of matching the counterpart of 
the trade. 

10 

The BIC table of FIG. 54 contains all generic information related to the 
financial institutions. The TFM processor validates the following input fields 
with the BIC table and process these detail only if the BIC is found to be valid. 

> IM 
15 > B/D 

> Settlement Location for ICSDs 

> GC for the allocation 

> Broker of Credit 

> Securities Agent at Location 
20 > Cash Agent at Location 

> Substituting Party 

> Accounting Agent 

> Reference Data Provider 

> Lending Agent 

25 > Concentrator participant AM 

> Domestic/Cross-Border TFM processor. 

The account of the participant at the settlement location is not identified by 
using BICs. SWIFT may assign and administer BICs for all GSTPA 
Participants. . 
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Account Identification 

The IM provides in the Allocation message the Account number of the 
client as per its internal records and the GCs client account number. The TFM 
processor does not perform any cross-referencing of the IM's account number 
5 to the B/D's internal account numbers. To enable the B/D to cross-reference 
between the IM's number and the B/D's internal reference number, the IM will 
also provide in the Allocation message the Access code relating to the vendor's 
system where the account number is registered, if it is indeed registered (e.g., 
in Alert, SID, etc.) The TFM processor will send this information to the B/D as 

10 part of the Allocation Notification. The B/D will interface with the vendor 
system for internal account set-up and cross-referencing purposes. The GC 
will receive the IM's account number and the GC*s account number as 
provided by the IM on the allocations. 

A process can be implemented to create a new, standard numbering 

15 scheme to identify accounts/portfolios. This involves the creation of a "Fund 
Registering Agency" that would allocate unique fund numbers for each 
account/portfolio that an institutional investor (e.g., a mutual fiind, a pension 
fund) would want to register. This registering agency would collect at that time 
the minimum amount of information about the account/portfolio that is needed 

20 for the IMs, the B/Ds, and the GCs to recognize this entity (e.g., tax domicile). 
The IM and the GC would use the unique number either directly or by cross- 
referencing. The association of this unique number with the IM BIC code 
would uniquely define the account for a B/D. The IM will identify their client 
account numbers as "Portfolio X," the GC will identify their client account as 

25 "Portfolio X" and the B/D will identify their client account as "Portfolio X at 
IM Y." 

The transition from the current situation to this new account numbering 
would be implemented as follows. Jn the early phase of the proposed scheme, 
the IM will submit its Account number, the GCs account number, and the 
30 Vendor Access Code and the GSTPA account number, if available. The B/D 
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will receive from the TFM processor, the IM f s account number, the Access 
Code and the GSTPA account number, if provided by the IM. The GC will 
receive from the TFM processor, the IM's account number, the GCs account 
number and the GSTPA account number, if provided by the IM. 
5 In the long term, the IM will submit the GSTPA account number only as 

part of the Allocation message. The B/D and the GC will receive the GSTPA 
account number from the TFM processor as part of the Allocation Notification 
and do the cross-referencing internally in their own applications. 

10 Participant Profile Data 

The Transaction Flow Manager (TFM processor) maintains a profile 
for each Participant of the GSTPA. The TFM processor Administrator does the 
initial set up of the primary details of the participant. Thereafter, the 
participants, using the profile message, will maintain the profiles. The 
IS Participant Profile contains information on the operating preferences of the 
Participants with respect to the TFM processor based on their internal operating 
procedures. 

A Participant Profile contains the information and the rules relating to the 
following; 
20 Participant Details 

• Participant Roles 

• Participant AM Details 

• Routing Details 

• Message Submission Modes 
25 • Substitution 

• Timing Rules 

• Matching Tolerance 

• Aggregation 

• Settlement Release 

30 • Profile for Broker-to-Broker Trades. 
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Profile Details - From the Role Perspective 

The Role Profile Table of FIG. 55 summarises the various profile 
categories applicable for specific roles. The Participant, using the messages 
5 defined for profile maintenance, can administer the Profile. The following 
information in the TFM processor can be maintained by axion4gstp as TFM 
processor System Administrator 

• Participant Primary details 

• Substitution 

10 • A Substituting Party for the specific role that is being substituted will 
maintain profiles. That is, if a substituting GC is submitting Settlement 
Details for a non-participating GC, the substituting GC can maintain GC- 
specific details such as Net proceeds & Settlement match deadlines, 
supported settlement bridges and so on, that are applicable for the specific 

15 role. Before an Accounting Agent starts maintaining its Profiles, TFM 
processor will validate whether an accounting agent has been appointed by 
the IM in its profile for the particular account. 

Profile Administration 

20 The Profile for a Participant is created when the TFM processor System 

Administrator defines the Participant in TFM processor. This will consist of 
certain basic mandatory information such as participant details, roles, and the 
default PAMs etc. that are required by the Participant to interact with the TFM 
processor. Any overriding values and operating preferences will need to be 

25 subsequently maintained by the Participant. 

Participants can maintain the following profile details in the TFM 
processor: 

• Gross amount match tolerance (IM, B/D) 

♦ Net proceeds match tolerance (IM,B/D) 

30 • Match of brokerage commission at block trade level (IM. B/D) 
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• Use of external common reference number match for applying tolerance 
on match of gross amount (IM, B/D) 

• Client Profiles (IM) 

• Accounting deadlines (Accounting Agent) 

5 • Routing details (IM,B/D, GC, Interested Parties) 

• Indicator for supported transaction type (B/D) 

• Notice of pending transactions (IM,B/D) 

• Settlement deadlines (B/D, GC) 

• Supported settlement bridges (B/D, GC) 

10 

Participants may add/replace/delete individual detail in the Profile using • 
"Maintain Profile" messages. Each add/replace/delete can be done in the 
Profile specifying the date that the values will become effective. The effective 
date along with the added/replaced/deleted profile detail can either be an 
15 immediate or a "future" date. The future date refers to a future system date 
except for routing details where the date specified refers to the future trade 
date. When an update to a Profile is effective immediately, the updated values 
will apply to all open transactions. 

• Any net proceeds that have failed match will be taken up for matching 
20 again if a Participant modifies the matching tolerance. However, any 

matched net proceeds will not be taken up for re-matching based on the 
new profile value. 

• If changes are made to deadline details in the Profile to be effective 
immediately, the new deadlines will be re-applied to all relevant open 

25 transactions, which have pending deadlines against them. 

All other profile updates will take effect only for new transactions submitted to 
the TFM processor. The TFM processor will maintain the log of all profile 
changes. The Participants can query their Profile details and log of changes. 
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Participant Details 

The basic information pertaining to a Participant in the TFM processor is set 
forth in the Participant Table of FIG. 56. 
5 Participant Identification: 

A Participant of the GSTPA is identified and represented in the TFM processor 
in the ISO standard Bank Identifier Code (BIC) format The BIC is a unique 
address that, in telecommunication messages, identifies precisely the financial 
institutions involved in financial transactions. The BICs are administered by 
10 S.W.I.F.T and arc meant for universal usage and not just on the S.W.I.F.T. 
network. 



Participant Address Details 

Participants may need to maintain one or more physical addresses with 
the TFM processor for the purpose of correspondence. A Participant can have 
one or more addresses representing the financial institution, various 
20 departments or transaction types. A particular address of the participant 
maintained in the TFM processor is stored in the Participant Address Table of 
FIG. 57. 

Participant Roles 

25 A Participant can assume one or more roles in its interaction with the . 

TFM processor. One or more of the following Toles can be defined for a 
Participant as shown in the Participant Roles Table of FIG. 58. 
Information based on a Participant-Role relationship consists of the following: 



30 



• Status of a Participant for the role. 

• TFMs and/or Concentrators to which a Participant is connected for a 
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role if applicable. 

• The messages that the Participant is authorised to send when acting in 
the given role. For example, with a role as GC, a Participant is only 
authorised to send the Settlement Details. 

5 

Participant Access Modules (AMs) 

Participant Access Modules (Participant AMs) provide a means of 
access to the TFM processor for Participants. The related information 
maintained in the TFM processor is stored in the Participant AM Identification 
10 Table of FIG- 59. 

Relationship between Participants 9 Roles, BICs, TFM processor, 
Participant AMs and Concentrators 

The information flow diagram of FIG. 60 illustrates the relationship 
15 between the Participants, BICs, Participant AMs, the TFM processor and the 
Access Concentrators. Observe the following points with reference to FIG. 60: 

1 . A Participant (8-Character BIC) can be associated with one or more roles 

2. A Participant can be associated with one or more 11 -character BICs. 
20 However, the first 8-characters of the BICs will always be the same and 

correspond to the BIC Identification of the Participant. 

3. A Concentrator can be associated with one or more Participants. These 
Participants can use a Participant AM owned by the Concentrator to access 
the TFM processor. 

25 4. A TFM processor can be associated with one or more Participants and a 
Participant can be connected to more than one TFM processor. 
5. An ^character BIC of a Participant can be associated with one or more 
Participant AMs owned by the Participant. Participants can assign 
optionally one of the Participant AMs to an 11 -character BIC. Each 11- 

30 character BIC can have a profile of its own, if the participant so desires. For 
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example, the 8-character BIC can have a routing profile that is different 
from that of the 1 1 -character BIC. 
6. A TFM processor can be associated with none, one, or several 
Concentrators. A Concentrator may be connected to one or more TFMs. 
5 7. A TFM processor can be associated with one or more Participant AMs, 
which it uses for its communication with the Participants. 
8. A Concentrator can own one or more Participant AMs. 

Routing Information 

10 Participants maintain routing information in their Profile to specify the 

Participant AM(s) at which different messages from the TFM processor will be 
received. By default, all messages are routed to the default participant AM 
associated with the applicable role of the Participant. The routing information 
can be set for the various categories of messages as explained below: 

15 

Error Messages 

Error messages are sent in the event of edit check failures and match 
failures. Error messages are always "pushed" to the Participants. If the 
Participant chooses to receive all error messages at a Participant AM that is 

20 different from the default Participant AM, this information will be specified in 
the Routing Profile, It is also possible to maintain different Participant AM(s) 
for error messages received at different stages of a trade. For example, the 
NOE acceptance error messages could be routed to a Participant AM that is 
different than the Participant AM to which net proceeds match failure messages 

25 are routed. 

Warning Messages 

Warning messages are sent in the event of non-critical errors during edit 
checks and matches. If there are warnings during an edit check or a match 
30 process, these will be sent to the Participant. The Routing details for warning 

107 



WO U3/065256 PCT/GB02/00463 

messages will specify the Participant AM(s) to which the warning messages are. 
to be routed. 



Success Messages 

5 Success messages are sent for successful acceptance and matches. A 

success message will be sent to the Participant only if the Participant opts to 
receive it. Hence, Participants could opt for success messages for matches 
alone, but not for acceptanceof messages. The routing information for success 
messages will specify whether the Participant opts to receive the success 
10 messages and the Participant AM(s) to which the messages are to be routed if 
different than the default Participant AM. 



Pending Processing Messages 

15 Pending messages are sent when messages are received out of sequence 

by the TFM processor due to network related problems (e.g., an Allocations 
message received by the TFM processor before the BON message from the 
IM). A Pending Processing message will be sent to the Participant only if the 
Participant opts to receive it. The routing information for the pending 

20 processing messages will specify whether the Participant opts to receive the 
pending processing messages and the Participant AM(s) to which the messages 
are to be routed if different than the default Participant AM. 

Warning for Pending Processing Messages 
25 Before discarding the messages received out of sequence by the TFM 

processor, it will generate a warning to the participant. This message will 
indicate that the TFM processor is likely to Discard Pending Processing 
Messages, if the earlier message on which this message is dependent is not 
received within xx minutes. This is an alert message and is not profile driven. 

30 
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Discard Pending Processing Messages 

Messages received out of sequence by the TFM processor due to 
network related problems (e.g., an Allocations message received by the TFM 
processor before the BON message from the IM) will be discarded by the TFM 
5 processor after a TFM processor defined wait period. The routing information 
for the discard pending processing messages will specify the Participant AM(s) 
to which the messages are to be routed if different than the default Participant 
AM. 

1 o Notification Messages 

Notification messages are sent to the Participants to notify them of 
crucial information such as the Match Reference Number, Match of Net 
Proceeds, Match of Settlement Details, Allocations to the B/D and GC, 
Pending Cancellations, and changed deadlines. Notification messages are 

15 always "pushed" to the Participants. If the Participant chooses to receive all 
notification messages at a participant AM other than the default participant 
AM , this information could be specified in the Routing Profile. It is also 
possible to maintain different participant AM (s) for notification messages 
received at different stages of a trade. For example, the Allocation notifications 
20 could be routed to a Participant AM other than the one used for all other 
notifications. The GC will receive Allocation notification messages prior to the 
matching of the trade, if they have specifically indicated such preference in 
their profile. In this case a normal Allocation notification message will be sent 
to the GC once the trade is matched and the Allocations are accepted from the 
25 IM. The GC who also acts as an accounting agent will receive separate 
messages for each of these two functions. 

Conversational Messages (Notice of Pending Transaction Messages) 

Conversational messages are sent to inform Participants of any Pending 
30 NOE. BON or Net Proceeds. The Participant will maintain in the Routing 
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Profile if any or all Conversational messages will need to be routed to a 
Participant AM other than the default Participant AM. 



Alert Messages (Time Expiry warning messages) 
5 The TFM processor will alert participants, if any of their trades or 

allocations is in jeopardy of missing a significant event like a settlement 
deadline or an accounting deadline. The routing information for alert messages 
will specify the Participant AM(s) to which the messages are to be routed if 
different than the default Participant AM. 

10 

Status Change Notification Messages 

Status Change Notification Messages are sent to the participant to 
indicate significant status changes for the trade. For example, when a block 
trade progresses from partially allocated to fully allocated, when all Net 

15 Proceeds for a block trade are matched or all settlement details for a block trade 
are matched* When a block trade is completed in all respects, a status change 
notification message will be sent to the Participant only if the Participant opts 
to receive it. The routing information for status change notification messages 
will specify whether the Participant opts to receive the status change 

20 notification messages and the Participant AM(s) to which the messages arc to 
be routed if different than the default Participant AM. 

Notice of Pending Transactions 

A Participant will choose to submit messages to the TFM processor 

25 either in independent mode or in conversational mode. In independent 
submission mode, Participants submit messages without being prompted by the 
TFM processor. In conversational submission mode, the Participant will 
respond to notice of pending transactions received from the TFM processor. 
However, the participants can submit a message in independent mode even if 

30 they have opted for conversational mode of data submission in their profiles. .. 
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The TFM processor will not validate an incoming message for the data' 
submission mode of the participant. 

The TFM processor sends notifications for any of the following 
transactions pending from a Participant - NOE, BON or Net Proceeds. Each 
5 Participant will specify in their Profile whether and when it wants to receive 
notification of pending transactions. If participants do not specify this 
information, the notification of alleged trade will be sent to the participants at 
the system default timing. The details maintained by the participant arc 
summarized in the Transaction Notification Table of FIG. 61. 

10 The timing of the notice of pending transactions will also be based on 

the deadlines (Le., end of the day for the market) even if the time specified for 
such notice has not elapsed. For example, if the participant has specified two 
hours for reporting the notice of pending NOE, but if the settlement deadline is 
earlier than this, then the timing of the notice of pending transaction will be at 

15 the time the warning for the settlement deadline is expected to be sent. 

Substitutions 

A Participant may be substituted for in terms of the submission of the 
Net Proceeds or the Settlement Details. The TFM processor administrator will 
20 maintain such substitution relationships in the TFM processor. 

Net Proceeds Substitution 

A B/D or an IM may outsource the Net Proceeds calculation and 
submission to a Third Patty. The profile of the B/D or the IM will contain 
25 details of the Substituting Party who is expected to submit the net proceeds. If 
substitution is defined for a B/D and the B/D itself submits Net Proceeds 
instead of the Substituting Party, the message will be rejected by the TFM 
processor. 

The Net proceeds substitution details maintained in the TFM processor consist 
30 of the details set forth in the Proceeds Substitution Table of FIG. 62. In 
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addition, IMs and B/Ds will be able to set up substitution for either a specific 
settlement location or a specific instrument type. For example Participant A 
can specify for settlement location 'Thailand" participant B will provide the 
net proceeds. 

5 

Settlement Details Substitution 

A non-participating B/D or GC can be substituted by a Participant of the 
TFM processor to submit the Settlement Details. The Substitution Profile Table 
of FIG. 63 stores the identification of the substitute who will be submitting the 

10 Settlement Details and the message type for which it is being substituted. The 
concerned B/D or the GC may appoint this substituting party. The IM can also 
appoint a substitute for non-participating B/D$ and GCs. When the non- 
participant GC does not appoint a substituting party, multiple parties can 
substitute. Therefore, the substituting party is identified by the combination of 

15 the identification of the EM and the GC. The Substituting Parties can maintain 
appropriate profiles for non-Participants. For example, if a non-participating 
GC is being substituted for Settlement Details, then the profile details such as 
settlement deadlines and so on can be maintained by the Substituting Party on 
behalf of the non-Participating GC. In addition, even participating GCs and 
20 B/Ds can set up substitution for either a specific settlement location or a 
specific instrument type. For example Participant A can specify for instrument 
type "Fixed Income" participant B will provide the settlement details. 

Client/Portfolio Details 

25 The Investment Manger maintains information regarding client 
accounts/portfolios in the TFM processor to enable processing based on this 
information. The following information will be maintained in the Profile of the 
IM/Accounting Agents for client accounts/portfolios: 

• The IM specifies the client accounts/portfolios and other details of die client 
30 accountfportfolio, such as class or category of the account/portfolio etc. 
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(e.g., US Insurance fund, UK mutual fund, etc.) The Standards Committee 
of GSTPA will standardise the class of accounts for use within the TFM 
processor environment. 

• The IM maintains the information about all the Accounting Agents 
5 associated with each of the client/portfolios. 

• Accounting Agents maintain the information of their Participant AMs for 
receiving accounting information from the TFM processor. Before an 
Accounting Agent starts maintaining its Profiles, TFM processor will 
validate whether an accounting agent has been appointed by the IM in it 

10 profile for the particular account. 

• The Accounting Agents will also specify the accounting deadlines with 
respect to the client accounts/portfolios. The Accounting Agent can specify 
accounting deadlines based on the class of client accounts/portfolios. The 
deadline is expressed as a time at which the TFM processor will report the 

15 accounting information, for all the confirmed and the unconfirmed trades 
belonging to that particular class of accounts, to the respective accounting 
agents. The Accounting Agent can also maintain, if required, stricter 
deadlines at the client account level If more than one accounting agent is 
appointed for an account, the stricter of the deadlines among the deadlines 

2D of the accounting agents for that particular account will apply. 

• For each client account/portfolio, the IM will also specify whether its net 
amount or the B/TVs net amount will be sent to the Accounting Agent, if the 
net amounts have not matched at the time of reporting. 

• In addition, the IM will maintain the time with respect to the deadline at 
25 which it and the B/D should receive an alert if the transaction remains 

unconfirmed. 

The accounting information sent by the TFM processor to the Accounting 
Agents will consist of the accounting data sent by the IM as well as selected 
trade and settlement details. 
30 The IM Client Profile Table of FIG. 64 illustrates the profiles 
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maintained by the IM for its Clients. 

The Accounting Agent Profile Table of FIG. 65 illustrates the profiles 
maintained by the Accounting Agent for its Clients. 

5 Examples of Deadline Setting for Accounting Agents: 
Example 1; 

Accounting Agent A for class of accounts "Mutual Funds Registered in 
Hong Kong" specifies a daily reporting based on the Allocation Time- The 
deadline is 5:00 PM Hong Kong time and the reporting duration is all the 

10 Allocations done from previous day 4:01 PM (-1 Days 4:01 PM) to 4:00 PM 
on the same day (0 Days 4:00 PM). 

A UK IM carries out two Allocations for a Mutual Fund registered in 
Hong Kong - one at 7:00 AM GMT and another at 9:00 AM GMT on 12 th 
June 2000 for Clients who are accounted for by Accounting Agent A. The 

15 Time Difference between UK and Hong Kong is 8:00 hours. At 9:00 AM GMT 
and 5:00 PM Hong Kong Time on the 26 th June 2000, both the Allocations 
have not been matched for Net Proceeds. TFM processor only reports the first 
Allocation as an unconfirmed (soft) accounting report to the Accounting Agent 
A. 

20 

Example 2: 

Accounting Agent A for class of accounts "Mutual Funds Registered in 
Hong Kong* specifies a daily reporting based on the Allocation Time. The 
Accounting Agent indicates that all Allocations should be reported 5 hours 
25 from the Allocation Time. In this case ail Allocations will be reported 5 hours 
from the submission time if they remain unconfirmed. 

Note: Confirmed reporting is not deadline based. Once the Allocation is 
matched for Net Proceeds, if there is any reporting requirement for the Client. 
30 The TFM processor will automatically cany out the reporting. The MIS will 
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keep track of confirmed reporting with respect to the deadlines established by 
the Accounting Agent 



Settlement Deadlines 

5 Please refer to the Alert and Deadlines processing for the profiles related 

to settlement deadlines. 

Matching Tolerances 

The following details on matching tolerance will be specified by a 
10 Participant in the Profile: 

(a) : Matching of Trade Price/Gross Amount 

Participants can maintain in their profiles whether they want an exact 
match on the trade price at the block level or not. If neither party requires an 
exact match on the average price in the block trade, a unilateral tolerance 

15 maintained by the participants at the settlement currency level by instrument 
type will be applied to the gross amount The Participants can define the 
unilateral tolerance amount for each currency by instrument type, which they 
would like to use for the gross amount match. Participants can define in their 
profile whether they would like to use an external common reference number 

20 match for applying the tolerance for matching of the gross amounts or not. 

The Matching Tolerance Table of FIG. 66 explains the matching tolerance at 
the level of the Block Cross Amount. 

(b) : Matching of Brokerage Commission 

Participants can specify whether they would like to match the brokerage 
25 commission at the block trade level exactly or not. If the participant has 
specified that exact match of commission is required, the trade will not be 
matched if the commissions do not match. If the Participant has indicated that 
exact match of commission is not .required, the trade will be matched if the 
commissions, do not match, but a warning will be issued indicating the 
30 commissions do not match. 
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Matching of Net proceeds 

Participants can specify the following details relating to tolerance values for 
net proceeds match: 

5 + Each Participant will maintain a unilateral preference with respect to 
prevailing amount if the net proceeds match within participant tolerance. 
The possible values for this preference will be: 

• 'Use my amount" "Use Counterpart's amount" or '"Neutral." 

• Unilateral Tolerance: The matching tolerance for a Participant will be 
10 specified as a % value. This is applicable for all currencies. In addition, the 

Participant can also specify a limiting amount at each currency level, which 
is the maximum amount up to which the % tolerance value will apply. 

• Bilateral Tolerance: Participants can also maintain different limiting 
amounts for different counterparts for a specified currency. 

15 This tolerance value will be applied if the net proceeds do not match within the 
market tolerance, which is maintained at the level of settlement location and 
settlement currency combination. 

20 Supported Transaction Types 

B/Ds can maintain in their profiles any requirements or preferences with 
respect to different product types. For example, a B/D will indicate in its 
profile whether Broker-to-Broker trades are to be processed by the TFM 
processor or not 

25 

Supported Settlement Bridges 

Participants (B/Ds and GCs) can maintain in their profiles the Settlement 
Bridge channels, which they would like to make use of through the TFM 
processor. They can also maintain the details of the currency of settlement and 
30 the type of instrument, which (hey would like to make use in each bridge 
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channel. The TFM processor will make use of this information while 
performing the match of settlement channel compatibility. 



Queries 

5 The Transaction Flow Manager (TFM processor) supports several types 

of queries by the participants. The basic principle of supporting queries is to 
enable participant's search the data for quick decisions. This enables the 
participants to achieve higher straight through processing rate in case of errors 
(data and match). The TFM processor provides unrestricted searchteccess to 

10 query data relating to own trades and profiles. The access to data of the other 
participants are restricted depending upon the sensitivity of the data. For the 
sensitivity/secrecy reasons, the data will be classified as Public domain 
information and Private domain information. While the public domain 
information can be queried by all participants, the private domain information 

15 can not be queried by other participants. 

The TFM processor supports various types of queries for different roles of the 
participants. In addition to supporting queries by the IMs, the B/Ds and the 
GCs, the TFM processor will also support queries by a Concentrator and the 
20 Accounting Agent. Certain category of participants will have the ability to use 
only certain types of queries. For example: Accounting Agents can query their 
own profiles only. Concentrator will be able to query only the trades submitted 
by a participant through them. The TFM processor provides for following types 
of queries by the participants. 

25 

> Trade Queries 

> Own Trades 

> Alleged Trades 

> Profile Queries 
30 > Own Profiles 
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> Counterpart profiles 

> Market Profiles 

> Reports 

> Performance Score Card 

5 

Trade Queries: 
Own Trades 

Participants will be able to query the data relating to own trades. Participants 
10 will be able to query the data on the block trade level as well as data on the 
allocation level. The data on block trade level can be queried using the Physical 
sender, Actual sender and Trade reference number as the key. For querying the 
data on allocation level, in addition to the Physical sender, Actual sender and 
Trade reference number, the participants have to use the Allocation sequence 
15 number as the key. Alternatively, participants can also use the Match Reference 
number as the key instead of their trade reference number. 

Participants can query both matched and unmatched trade records. 
Participants will be able to query the status of their trades. For example: 
20 Participants will be able to query all the trades, which are not fully allocated. In 
addition, they can query the status of an allocation. 

Participants can also search based on the combination of die following 
attributes of the trade giving range of values: 
25 > Trade reference numbers 

> Match reference numbers 

> Block quantity trades 

> Trade prices 

> Block gross amounts 
30 > Trade dates 
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> Settlement dates 

> Allocation sequence numbers 

> Allocated quantities 

> Net Amounts 

5 

Participants can also query their trades with the following attributes: 

> Counterpart 

> Transaction type 

> Instrument Type 
10 > Buy or sell trades 

> Security Identification number 

> Trade or Settlement Currency 

> Setdement location 

> Client Account number 
15 > GC or a Local Agent 

Alleged Trades 

Participants can query the trades alleged against them, which are waiting for 
their response. They can query the unmatched trade data for the trades alleged 
20 against them by following attributes: 

> Counteipart 

> Class of financial instruments 

> Transaction types 

> Security identification numbers 
25 > Settlement locations 

> Settlement currency 

> Buy or sell trades 

The queries can also have range of values for search criteria like block 
quantity, block gross amount, trade date and settlement date. 
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Profile Queries 
Own Profiles 

Participants can query the profile data maintained by them in the TFM 
5 processor. Participants can query the various types of profile information like 
Matching tolerances for gross amount and net amounts (both unilateral and 
bilateral), class of accounts and related accounting deadlines, routing profiles, 
aggregation profiles, settlement deadlines etc. Participants will also be able 
queiy the log of changes done between a period on their profile information. 

10 

Counterparty Profiles 

Participants can query the data relating to their counterparts. Query of the 
counteiparty profiles will be role dependent. For example; An IM will be able 
to query the public domain profile of the counterpart B/D. However, an IM will 
15 not able to query the profiles of another IM, They will be able to query only 
the public domain profiles. The decision of whether a profile is public or 
private will be determined using the TFM processor system parameter for the 
profile* The GSTPA operations committee may decide which profiles will be 
public and which ones are private. 

20 

Market Profiles 

Market Profiles are the information relating to various currencies, settlement 
locations etc maintained by the TFM processor Administrator for the 
functioning of the TFM processor. Participants will be able to query the 
25 information relating to Market tolerances, Deadlines for settlement locations 
and other system level parameters. 

Performance Queries 

The overall performance of the TFM processor and the participants in terms of 
30 statistics of its trade/message activities will be reported on a daily basis. The 
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TFM processor will also maintain these statistics at the level of the following 
time frames: 

> Monthly 

> Quarterly 
5 > Yearly. 

Trade Statistics 

With reference to the Trade Statistics Table of FIG. 67, Trade statistics provide 
the following information regarding the submitted trades, successful trades, the 
cancelled trades by the TFM processor, and the cancelled trades by 
10 participants. The percentage is estimated based on its respective numbers 
corresponding to trades submitted. 
These statistics are broken down by: 

> Participant 

15 > Market (Settlement Location) 

> Instrument Type 

> Settlement Currency. 

Individual participants will be able to query these statistics pertaining to them. 

20 Message Statistics 

Message statistics provide the counts of the messages with respect to its 
functionality. Refer to the Message Statistics Table of FIG. 68 for further 
details. 

These statistics are broken down by: 

25 

> Participant 

> Market (Settlement Location) 

> Instrument Type 

> Settlement Currency. 
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Individual participants will be able to queiy these statistics pertaining to them. 

Matching Efficiency 

Match statistics provides the counts of matched events (trade match, 
5 allocation completion, NP Match, and SD Match), missed deadlines, and 
matching efficiency. With reference to the Matching Efficiency Table of FIG. 
69, matching efficiency is shown as the number and percentage of events 
completed in different time intervals. The percentage is estimated based on the 
coiresponding number for trades and allocations submitted. For the purposes of 
10 benchmarking the value of block trades reported in different currencies, the 
TFM processor will use a base currency and an exchange rate between the base 
currency and the trade currency. 
These statistics are broken down by: 

> Participant 

15 > Counter Participant 

> Market (Settlement Location) 

> Instrument Type 

> Settlement currency. 

20 Individual participants will be able to query these statistics pertaining to it and 
its counter participants. 

Geographical characteristics of Usage 

Statistics on completed trades with respect to geographical usage are 
provided in the Geography Table of FIG. 70. 

25 Instrument Types of Usage 

Statistics on completed trades with respect to the instrument types are 
stored in the Instrument Type Table of FIG. 71. 
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Domestic or Cross-border Usage of Services 

Statistics on completed trades with respect to the type of service are 
provided in the Type of Service Table of FIG. 72. 
- A domestic trade is the one where all the participants to the trade are from 
5 the same country where the security is issued. 

Standards Compliance 

Statistics on completed trades with respect to securities identification 
code usage are provided in the Standards Compliance Table of FIG. 73. 
These statistics are broken down by: 
10 > Participant 

> Market (Settlement Location) 

> Instrument Type. 

Individual participants will be able to query these statistics pertaining to them. 
15 Mssage Handling and Trade Referencing 
Reference Numbers 

A trade is uniquely identified within the TFM processor as a combination of 
the following: 

20 • Actual Sender Identification: This is represented by the BIC of the actual 
sender. 

• Physical Sender Identification: Participants can identify their trades 
submitted through concentrators by using the physical sender identification 
of the concentrator as part of the trade identification. This is represented by 

25 the BIC of the physical sender. 

• Participant's Trade Reference number: This is a unique block trade 
reference number created by th$ participant for submission of trade details 
into the TFM processor. 

Each participant (IM or B/D) will use their own trade identification number to 
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submit messages relating to a given trade into the TFM processor. An 
allocation is uniquely identified within a trade using an Allocation Sequence ' 
number as supplied by the allocating party. The GC will use the IM's Trade 
and Allocation identification to submit the settlement details. 
5 The TFM processor Match Reference Number is a unique trade 

reference number generated by the TFM processor for every block trade match. 
This number will be sent to both the IM and the B/D after the BON/NOE 
match takes place. 

In addition to these reference numbers, the TFM processor and the Participant 
10 AM will also issue a unique reference # to acknowledge every message 
received by the TFM processor and the Participant AM called, the Receipt 
Reference #. 

Message Versions 

15 Every input message relating to a trade will be assigned a version 

number by the participant. The objective of the message versioning is to check 
if the participant is intending to use the version of currently stored details 
within the TFM processor. The other objective of the message version is to 
ensure that the right sequence of cancel/replace/delete messages is applied. 

20 The Message structure will accommodate a version number on the trade level 
messages and separate versions for individual allocations within the same 
message. 

Allocation level messages will use the trade reference number and 
message version number of the BON/NOE to identify the trade. Allocation 
25 sequence numbers and their message version numbers will be used to identify 
allocations. 

Each Net Proceeds and Settlement Details message will have its own 
version numbers for individual allocations, besides explicitly stating the trade 
version numbers and allocation version numbers. 
30 The Reference Numbers Table of FIG. 74 illustrates the reference 
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numbers used during the trade life cycle by each participant to the trade. 
All cancellations and replacements will require a new version number higher 
than that of the version currently stored in the TFM processor. If the TFM 
processor receives a replace and the corresponding new message with version 1 
5 has not arrived, then the TFM processor will process it as a new message. If the 
TFM processor receives a cancellation or a deletion message and the 
corresponding new message with version 1 has not arrived, then TFM 
processor will validate the cancellation or deletion message and create a 
transaction in "Cancelled" or 4I Deleted" status. The TFM processor will 
10 validate the current version number stored with the version number indicated in 
the incoming messages. If the message fails the version number validation (i.e., 
the message version is not higher than the current version), it will be rejected. 
Example 1: 

Participant A sends a new block trade with trade reference # A1234 and 
15 version 1. Participant A also immediately senids a replace message to the trade 
with reference # A 1234 with version 2. Due to network delays, the replace 
message arrives before the new message to the TFM processor. The TFM 
processor processes the replace message as though it is a new message. When # 
A1234 version 1 arrives, the TFM processor ignores it as the TFM processor 
20 has already processed version 2 of the trade. 
Example 2; 

Participant A sends a new block trade with trade reference # A1234 and 
version 1. Participant A also immediately sends a cancel message to the trade 
with reference # A1234 with version 2. Due to network delays, the cancel 

25 message arrives before the new message to the TFM processor. The TFM 
processor processes the cancel message. If all the validations for die cancel 
message are successful, then the TFM processor creates a trade in cancelled 
state. Once the new trade arrives, TFM processor ignores the new block trade 
message as it has already processed version 2 of the trade. 

30 The following are the sequence of messages expected from the IM: 
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1 . Block Trade Details (Block Order Notification) 

2. Allocations 

3. Net Proceeds and 
5 4. Settlement Details. 

The following are the sequence of messages expected from the B/D: 

1 . Block Trade Details (Notice of Execution) 

2. Allocations (for pre-allocated trades) 

3. Net Proceeds and 
10 4. Settlement Details. 

The following are the sequence of messages expected from the GC: 
1. Settlement Details. 

If the sequence of the arrival of the messages for a particular trade reference # 
15 and version # is not maintained by the network, then the TFM processor will 
keep the out-of-sequence message in pending processing state until the higher 
level messages arrive and is accepted by the TFM processor (Examples 1 and 2 
below). 
Example 1: 

20 Participant A sends a new block trade message with reference U A 1234 and 
Version 1. Participant A also sends immediately an Allocation Message with 
Allocation Sequence # 1 and version L The Allocation message arrives before 
the block trade messages. The TFM processor keeps the Allocation Message 
pending for acceptance until the new block trade message is accepted by the 

25 TFM processor. Once the new Block Trade is accepted by the TFM processor, 
the TFM processor processes the pending Allocation Message. 
Example 2: 

In the TFM processor, there is already a trade with reference U A 1234 and 
version 1 and Allocation with sequence # 1 and version L Participant A sends a 
30 replace to the block trade with version 2 and increases the block quantity. 
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Participant A also sends a replace message to the Allocation with version 2 and 
increases the Allocated quantity. The Allocation Message arrives before the 
Block Trade replace message. In this case, the processing in the TFM processor 
is exactly similar to the one mentioned in Example 3. 
5 The TFM processor will time-out and discard pending processing 

messages after a system-specified duration. TFM processor will also issue a 
warning message to the participant about the discard of pending processing 
messages. For example, if the Allocations message arrives prior to the Block 
Trade message from an IM, then the TFM processor will issue a warning to the 
10 participant after a system parameter (e.g., 2 minutes) of the arrival that it is still 
awaiting the Block Trade message. The TFM processor will issue a discard 
notification and discard the Allocations message, if after a system parameter 
(e.g., 5 minutes) from the arrival of the Allocations, the Block Trade message 
does not arrive. 

is 

New Message Acceptance Process 
• Format Validation 

• All messages are checked for adherence to a protocol as, for 
example, for XML compliance, DTD validity and format (datatype) 

20 and constraints (conditions). If the format validation fails, error 

messages are generated and sent to the sender of the message. 

» Sequence Checks 

• Participants may send their messages to the TFM processor in any 
25 sequence. The TFM processor will process the incoming messages 

in the required sequence. 

• The Sequence check is performed on all input messages except NOE 
and BON. Sequence checks will check the existence of a trade and 
allocations as well as their versions and status. If the trade or 

30 allocation does not exist, messages are put in "Pending Processing 1 * 
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status. 

• All messages in "Pending Processing" status will be processed after 
the corresponding trade or allocation details are subsequently 
processed by the TFM processor. If the corresponding trade or 

5 allocation details do not arrive within a specified time, the TFM 

. processor will send an alert to the participant. 

• If the corresponding trade or allocation details do not get accepted 
within a specified escalation time after alerts, this "Pending 
Processing" messages would be "Rejected," as part of the TFM 

1 0 processor housekeeping procedure. 

• If the sequence context check fails for status (e.g., new allocations 
for a fully allocated trade with an existing allocation sequence and 
version), then messages are "Rejected." 



15 • Content Validation 

Content validation is perfoimed on all input messages by the TFM 
processor against the reference data and existing details. It will generate 
error and warning codes as applicable. If the validation has only warnings 
and no errors, acceptance messages are generated based on profile settings. 
20 If validation has failed with errors, error messages are sent to the sender. 

If a participant operates in conversational mode and chooses to receive the 
notice of pending transaction immediately, the TFM processor will generate 
and send a notice of pending transaction. If the counterpart operates in 

25 independent submission mode and chooses to receive the notice of pending 
transaction after either a profile- based duration or a system-specified duration, 
the TFM processor will generate and send the notice of pending transaction 
after the lapse of the duration. The system-defined duration of time between the 
time that a trade is alleged and the time that the counterpart receives the notice 

30 of pending transaction will account for relevant deadlines. 
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Some message acceptances will also generate notification messages (e.g., 
allocations acceptance will send allocation details to the B/D and the GC). 
Refer to the Message Status Table of FIG. 75 for further details. 

5 Input Messages 

Input Messages to the TFM processor include any of the following: 

> Notice Of Execution 

> Block Order Notification 

> Allocations 
10 > Net Proceeds 

> Settlement Details 

> Accounting Information 

> Participant Profile. 

Input messages specify the function of the message, as shown in the Message 
15 Function Table of FIG. 76. Input messages include the senders* details, trade 
identification, allocation identification and version number details. 

Multi-part Messages 

Related messages to a trade from a participant can be submitted as a 
20 multi-part message. The message acceptance process of the TFM processor 
will split the multi-part message into single pieces and accept them 
individually. 

Output Messages from the TFM processor 
25 Output messages generated from the TFM processor will fell into the 

following broad categories, with reference to the Message Types Table of FIG. 
77. 

30 Error and warning Message 
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All error and warning messages will have trade identification, trade 
version numbers, allocation identification, allocation version numbers, and 
individual message versions. All error messages will have error codes and error 
field tags. Match error and warning messages will also have the party's value 
5 and counterpart's value. Warnings will be sent along with errors or acceptance 
messages. 

Acceptance Message 

The TFM processor generates acceptance messages for successful 
10 validations. This can be profile driven. The acceptance messages will also 
contain the status, the trade details and the allocation identification details. 



Pending Processing Message 

The TFM processor will generate a pending processing message for messages 
15 arriving out of sequence. This can be profile driven. 



Discard Pending Processing Message 

The TFM processor will generate a discard message for any pending 
processing message that has timed out This can be profile driven. 

20 

Notice of Pending Transaction Message 

In their profiles, participants will specify whether they will operate in 
conversational or independent submission mode with respect to alleged trades. 
Participants that operate in conversational mode will receive notification of 

25 pending transactions immediately after the trade has been alleged against them. 
Participants that operate in independent submission mode will receive 
notification of pending transactions either after a profile-based duration or a 
system -defined duration in the absence of any profile. The system-defined 
duration of time will need to account for relevant deadlines. 

30 Block Trade and Net Proceeds are the events for which the TFM 
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processor wil] generate notice of pending transaction against the counterpart. 



Match Notification Message 

Match Notification Messages for all matches are pushed by the TFM processor 
5 as part of the basic functionality and are not profile driven. 

Notification Message 

Allocation details and accounting information are notification messages that 
are pushed by the TFM processor as part of the basic functionality. Settlement 
10 Release can be profile driven. 

Status Change Notification Message 

Status changes of a trade or trade allocations can be sent to the participant by 
trade identification, allocation identification and status of trade and allocation. 

15 

Alert Message 

Alert messages are sent by the TFM processor to participants to warn them 
early about deadlines that are about to expire. For example, the TFM processor 
will send an Alert message to the B/D and GC one-hour (a system parameter) 
20 before the settlement deadlines if either party has failed to input the settlement 
details. 

With reference to the Block Trade states Table of PIGS . 78, 
78A and 78B the composite Block Trade State is a combination 
25 of the Block Trade State and Block Trade Allocation Sub-State. 
The composite Allocation State is a combination of the 
Allocation State and HP state and SD state. 



30 
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Input and Output fields 

FIG. 79 describes the field elements defined for the TFM processor, along with 
the associated edit checks for the fields. This Appendix also contains the list of 
input and output messages and the mandatory, optionality, and conditionality of 
5 the field elements in the physical messages. A cross-reference to physical and 
logical messages has also been provided. 

Input Messages 

FIG. 80 describes input message field elements and describes which fields are 
10 needed in which messages, the mandatory or optionality of the fields in the 
message, whether the field is matched or not. 

Output Messages 

In the TFM processor, there are two types of output messages: (a) one to notify 
15 the participant about the details of the trade or allocations and the outcome of 
the matches like Block Trade match notification, Allocation Notification to the 
GC, Allocation Notification to the B/D, Net Proceeds Match Notification, 
Settlement Details match notification, Settlement Release Notifications, and (b) 
another to notify about an acceptance errors, status changes. 

20 

Messages sent with Trade and Allocation details 

The data structure diagram of FIG. 81 groups field elements by input messages 
and describes which fields are needed in which messages, the mandatory or 
optionality of the fields in the message, and whether or not the field is matched. 
25 Legend for Reading FIG. 8 1 (as well as other data structure diagrams presented 
herein): 

M - Mandatory Field 
O- Optional Field 

C - Conditional Field. The presence of the field is dependent on the values 
30 specified in other fields. Please refer to Section LI Field Elements for details 
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of the conditional rules. 

TFM processor - The sender identification of the TFM processor. 
BM, BO, BC - "B" indicates both sides values for settlement details. "M", 
"0" "C" Indicates mandatory, optionality and conditionality of the fields. 
5 G - Fields generated by the TFM processor 
CM - Fields sent only if the trade is matched 

PM, PO, PC - "P" indicates either the prevailing side's net amount in case of 
Net Proceeds Match or the both sides net amounts in case of Net Proceeds 
match failure, "M", "O", "C" Indicates mandatory, optionality and 
10 conditionality of the fields. Global Custodian will only get the prevailing sides 
Net Proceeds details. Accounting Agents will be reported based on the profile 
(either Investment Manager's values or Broker/Dealers values) 
CK - Fields only used to carry out control checks against the referenced Block 
Trade or Allocations. 

15 

The following are the list of output messages with trade details that are sent by 
the TFM processor: 

> Alleged NOE and BON to indicate to the counter party about the alleged 
trades 

20 > Trade Match and Trade Pair notification (Trade Match + Pair) to indicate 
the matching of the trade or the pairing of the trade due to replace of trade 
details by one of the parties. The details will be similar to the NOE or BON 
and will contain the counter party's trade details. 

> Allocation notifications to the Global Custodian (certain fields like 

25 settlement location etc., will be sent only if the trade has matched with the 
NOE) 

> Pending Net Proceeds (NP Pend) in case the participant is operating in a 
conversational mode 

> Net Proceeds match and match failure notification (NP Match) indicating 
30 the prevailing amount or the counterparts amount respectively 
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> Settlement Details match and match failure notification (SD Match) 

> Settlement Release details (SD Release) 

> Accounting Details (Acct) 

5 Messages sent with only reference and status details 

These messages are used to send out successful acceptance of messages 
or a rejection of the messages due to validation failures. These messages are 
also used to send any alert notifications to participants to inform them about 
any deadlines that are going to expire and status changes to trades. Pending 

10 processing, alert for pending processing and discard message will be sent as an 
Alert message with appropriate status in Status of the message field. Deadline 
change notification will be sent as success messages with the revised deadlines. 

The data structure diagram of FIG. 82 groups the field elements by input 
messages and describes which fields are needed in which messages, the 

15 mandatory or optionality of the fields in the message, whether the field is 
matched or not etc.,. In addition to these fields, there will also control check 
fields to ensure that participants refer to the right details of the trade and 
Allocations. These control check fields are not added in the table. 

20 Mapping of Logical Messages to Physical Messages 

Block Trade Details are shown in the data structure diagram of FIG. 83 (for 
Input Messages) and the data structure diagram of FIG. 84 (for Output 
Messages). FIG- 85 is a data structure diagram showing input messages for 
allocations, and FIG. 86 is a data structure diagram showing output messages 

25 for the above-described allocations process. FIG. 87 is a data structure 
diagram showing input messages for the above-described Net Proceeds 
process, and FIG. 88 is a data structure diagram showing output messages for 
the Net Proceeds process. 

FIG. 89 is a data structure diagram showing output messages related to 
30 Accounting Details, FIG. 90 is a data structure diagram showing input 
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messages involving Settlement Details, and FIG. 91 is a data structure diagram 
showing output messages involving Settlement Details. 



Process Variations 

S 

Broker-to-Broker Trade 

B/Ds can report and match their broker to broker trades using the TFM 
processor. The decision to route broker-to-broker trades to the TFM processor 
will decided by the participant based on the underlying market infrastructures 
10 that already provide such matching facilities for broker-to-broker trades. 

B/Ds can indicate in their profiles, whether they would be using the 
TFM processor for matching broker-to-broker trades. If the one of the B/D in 
the broker-to-broker trades indicate that they do not want to use the TFM 
processor for Broker-to-Broker trades, TFM processor will not process the 
15 broker-to-broker trade. In this type of trade, one of the B/D (called as the 
executing broker) will provide the NOE and the counter party broker will 
specify the BON. The executing broker will provide all the details which in the 
normal institutional trade, a B/D will provide. This includes the proposed 
settlement location. The processing type will be set as "Broker-To-Broker 
20 trade" by both sides. On acceptance of the NOE and BON for a Broker to 
Broker trade, TFM processor will verify the profile of the parties to the trade to 
find whether they would support the Broker to Broker trade within the TFM 
processor. If both the parties to the trade have indicated in their profile to 
support the Broker to Broker trade, TFM processor will further process the 
25 trade. Otherwise, the trade will be rejected and an error message will be sent to 
the Broker submitting the NOE/BON. There will not be any other processing 
variations in the Block trade processing for the Broker to Broker trades. 

Broker to Broker trades will not have any allocation process, as these 
trades arc not for identified underlying funds/portfolios, TFM processor will 
30 not have allocation process for Broker to Broker trades. 
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Participants can submit all other details i.e. Net Proceeds and Settlement 
Details for a Broker-To-Broker trade using a multi-part message along with 
trade details. Alternatively, participants can also provide Net Proceeds and 
Settlement details message separately. TFM processor will carry out the net 
5 proceeds match and the settlement channel compatibility matches for the 
Broker-To-Broker Trades. 

The TFM processor will match Net Proceeds provided by both the B/Ds 
after successful match of the trade. The proposed settlement location provided 
by the executing Broker will be used for the determination of applicable market 
10 tolerance. This process is same as the normal institutional trade. The TFM 
processor will also match Settlement Details provided by both the parties to the 
trade. In case of a normal institutional trade the GC of the underlying client 
provides the IM's side of the Settlement Details. But, in case of Broker to 
Broker trades, both the parties to the trade provide the settlement details. There 
15 is no processing variation for the matching of settlement details of Broker to 
Broker trade within the TFM processor. 

It is expected that Broker to Broker trades will not be reported to the 
TFM processor, if the counterpart is.not a TFM processor participant 

20 Fund to Fund Trade 

Fund to Fund trades can be submitted by either the same Wl to handle 
internal crossings between two funds or by two IMs if they have traded using 
electronic networks like Instinet or E-crossnet Funds to Fund trades are treated 
as a separate processing type within the TFM processor. The parties to the trade 
25 while reporting the trades will identify the trade as i4 Fund to Fund trade" as the 
processing type. 

Fund to Fund trades will have two legs of trade. Both the legs of the 
trade are treated as normal institutional trades within the TFM processor. The 
Investment Managers) will be able to link these two institutional trades by 
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using a Fund-to-Fund link reference number. The virtual broker will act as a 
common broker for both legs of the trade and will provide the Fund-to Fund 
link reference number while submitting the NOE for both legs of the trade. A 
virtual broker is either a clearing account in case of internal crossings or an 
5 institution providing the fund to fund crossing services (like E-crossnet). The 
other side of the trade will submit a BON. The information flow diagram of 
FIG. 92 explains the handling of a Fund-to-Fund trade. 

The common virtual broker submitting an NOE for a Fund to Fund trade 
could have a role of an IM or a B/D. There are no other process variations 
10 within the TFM processor for handling of block trade processing of Fund to 
Fund trade. 

The TFM processor will receive the Allocations from the IM and process the 
Allocation like any other institutional trade. No process change is envisaged 
for Allocation processing for fund to fond trades. This process enables 
15 Allocations on the buy side of the fund to fund trade and Allocations on the sell 
side of the fund to fond trade, to flow the information to the GCs of the 
underlying Funds. 

Refer to the information flow diagram of FIG. 93 wherein the IM can submit 
all Net Proceeds Details for a Fund to Fund trade using a multi-part message 
20 along with allocation details. Alternatively, IM can also provide Net Proceeds 
and Allocation details message separately. The common virtual broker can 
submit the Net Proceeds and Settlement details in a multi-part message or in a 
separate message. TFM processes' will carry out the net proceeds match and 
the settlement channel compatibility matches for the Fund to Fund Trades. 
25 The TFM processor will match Net Proceeds provided by both the 
participants after successful match of the trade. The proposed settlement 
location provided by the common virtual Broker will be used for the 
determination of applicable market tolerance for the trade. This process is same 
as the normal institutional trade. 
30 The clearing agent of the common B/D will act as a link for settlement of 
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these trades. The settlement is done between the custodians of the underlying 
funds and the settlement agent of the counterpart. Two legs of these trades are 
settled via the intermediate counterpart. No process change is envisaged for 
settlement details processing. 



Basket/Program/Portfolio Trading 

Participants report and match separately the trades as individual 
institutional trades for each underlying security of the basket/program/portfolio 

10 trade. The trade transaction type will be reported as "Basket/Program/Portfolio 
trade". Participants specify a common Basket reference number for the 
underlying institutional trades of a basket. The Trade details relating to every 
Security comprised in the basket will be linked with this Basket Reference 
number given by the B/D. TFM processor will support queries to participants 

15 based on the basket/program/portfolio trade reference number. A typical 
basket/program/portfolio trade will be a pre-allocated trade where the B/D will 
specify the allocations for the underlying institutional trades. The IM or the 
B/D providing the Allocations will provide allocation quantities on an absolute 
basis for each Security comprised in the basket for each allocated client. TFM 

20 processor will not support the percentage allocations. The percentage 
allocations will have to be internalized by the participants in their applications. 
Separate allocation message will be sent for various securities comprised in the 
basket. 

No Process change is envisaged in Ac processing of a 

25 Baskct/Program/Portfolio trades. 

It will be readily seen by one of ordinary skill in the art that the present 
invention fulfills all of the objects set forth above. After reading the foregoing 
specification, one of ordinary skill will be able to effect various changes, 
substitutions of equivalents and various other aspects of the invention as 

30 broadly disclosed herein. It is therefore intended that the protection granted 
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hereon be limited only by the definition contained in the appended claims and 
equivalents thereof. 
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We Qaim: 

1 . A system for matching post-trade, pre-settlement information for a 
securities transaction, the system comprising: 

(a) a communications mechanism adapted to transmit and receive 
transaction parameter messages setting forth one or more parameter values 

5 related to a securities transaction; 

(b) a processing mechanism, coupled to the communications 
mechanism, and adapted to determine matches between one or more parameter 
values of any two or more transaction parameter messages; 

wherein the processing mechanism is further adapted to transmit an 
10 indication message over the communications mechanism, the indication 

message specifying at least one of: (i) the existence of matches between one or 
more parameter values of any two or more transaction parameter messages; and 
(ii) the non-existence of matches between one or more parameter values of any 
two or more transaction parameter messages. 

2. The system of claim 1 wherein one or more respective parameter 
values are associated with corresponding tolerances setting forth a maximum 
acceptable deviation for the respective parameter value, and the processing 
mechanism is further adapted to identify matches between parameter values 
5 within the maximum acceptable deviation. 
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3. The system of claim 1 wherein the communications mechanism is 
further adapted to accept incoming transaction parameter messages related to a 
first securities transaction and incoming transaction parameter messages related 
to a second securities transaction; and 
5 wherein the processing mechanism includes a discrimination mechanism 

adapted to distinguish incoming transaction parameter messages related to the 
first securities transaction from incoming transaction parameter messages 
related to the second securities transaction; the processing, mechanism adapted 
to determine matching within a predetermined tolerance and/or compatibility 
10 between two or more incoming transaction parameter messages related to the 
first securities transaction, and the processing mechanism also adapted to 
determine matching within a predetermined tolerance and/or compatibility 
between two or more incoming transaction parameter messages related to the 
second securities transaction. 

4, The system of claim 1 wherein the incoming transaction parameter 
messages include parameter values specifying at least one of: (a) block trade 
details, (b) allocation details, (c) net proceeds details, and (d) settlement details 
for the securities transaction. 

5. The system of claim 1 wherein the incoming transaction parameter 
messages include parameter values specifying at least one of: 

(a) a first set of one or more block trade details, (b) a first set of one or 
more allocation details, (c) a first set of one or more net proceeds details, and 
5 (d) a first set of one or more settlement details; 
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and parameter values specifying at least one of: 

(e) a second set of one or more block trade details, (f) a second set of 
one or more allocation details, (g) a second set of one or more net proceeds 
details, and (h) a second set of one or more settlement details; 
10 wherein the processing mechanism determines compatibility by 

identifying any matches between (a) and (e), (b) and (f), (c) and (g), and/or (d) 
and (h). 

6. . A system for matching post-trade, pre-settlement information for a 
cross-border securities transaction between a first party and a second party, the 
first party being a seller or a seller's representative and the second party being a 
buyer or a buyer's representative, the transaction being defined by a plurality of 
5 parameters, the system comprising: 

an input mechanism adapted for receiving a message from the seller or 
the seller's representative and a message from the buyer or the buyer's 
representative, said messages each setting forth at least one value for at least 
one parameter relating to the transaction; 
10 a processing mechanism comprising a data storage for parameter values 

and a processor for comparing parameter values for each of a plurality of 
parameters to identify at least one of compatible and incompatible parameter 
values; and 

a communications mechanism coupled to the processing system for 
15 providing an output message indicative of at least one of: (i) identification of 
compatible parameter values; and (ii) identification of incompatible parameter 
values. 

7. The system of claim 6, wherein a parameter comprises a value 
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and a tolerance for the value. 

8. The system of claim 7, wherein the processing mechanism 
determines whether a parameter received from the first party is within the 
tolerance for the value received from the second party. 

9. The system of claim 6, wherein a parameter has a default value. 

1 0. The system of claim 6, wherein a parameter has a default 
tolerance. 

1 1 . The system of claim 6, wherein a parameter identifies the seller 
or the seller's representative and the buyer or the buyer's representative. 

12. The system of claim 6, wherein the processing mechanism 
assigns a unique identifier to a particular transaction. 

13. The system of claim 6, wherein a parameter identifies a custodian 
for the seller's transaction. 
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14. The system of claim 13, wherein a parameter further 
identifies a custodian for the buyer's transaction. 

15. The system of claim 13, wherein the processing mechanism 
notifies at least one custodian of a consummated transaction. 

16. A system for matching post-trade, pre-settlement information for a 
cross-border securities transaction between a seller's representative and a 
buyer's representative, the transaction being defined by a plurality of 
parameters, the security being held by a custodian, the system comprising: 

5 a communications mechanism for receiving messages from the seller's 

representative and the buyer's representative, said messages comprising values 
for the parameters relating to the transaction; 

a processing system comprising data storage for parameter values and 
notifying the seller's representative and the buyer's representative of the 
10 parameters for a securities transaction; and 

an indication mechanism for providing an indication to the 

communications mechanism which is indicative of one or more parameters for 

the securities transaction. 

17. A method of matching post-trade, pre-settlement information for a 
cross-border securities transaction, the method including the steps of: 

(a) receiving transaction parameter messages setting forth one or more 
5 parameter values related to a securities transaction; 

(b) storing transaction parameter messages; 
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(c) determining matches between one or more parameter values of any 
two or more transaction parameter messages related to the securities 
transaction; 

10 (d) transmitting an indication message specifying at least one of: (i) the 

existence of matches between one or more parameter values of the any two or 
more transaction parameter messages; and (ii) the non-existence of matches 
between one or more parameter values of any two or more transaction 
parameter messages. 

18. The method of claim 17 further including the steps of; 
(a) accepting transaction parameter messages related to a first securities 
transaction and transaction parameter messages related to a second securities 
transaction; 

5 (b) distinguishing incoming transaction parameter messages related to 

the first securities transaction from incoming transaction parameter messages 
related to the second securities transaction; and 

(c) determining compatibility between two or more incoming transaction 
parameter messages related to the first securities transaction. 

19. The method of claim 18 further including the step of determining 
compatibility between two or more incoming transaction parameter messages 
related to the second securities transaction. 



145 



WO 03/065256 



PCT/GB02/00463 



20. The method of claim 17 farther including the steps of: 
accepting incoming transaction parameter messages related to a first 
securities transaction and specifying at least one of: (a) a first set of one or 
more block trade details, (b) a first set of one or more allocation details, (c) a 
5 first set of one or more net proceeds details, and (d) a first set of one or more 
settlement details; 

and accepting incoming transaction parameter messages specifying at least one 
of: 

(e) a second set of one or more block trade details, (f) a second set of 
10 one or more allocation details, (g) a second set of one or more net proceeds 
details, and (h) a second set of one or more settlement details; and 

determining compatibility by identifying any matches between (a) and 
(e), (b) and (f), (c) and (g), and/or (d) and (h). 

21. A post- trade, pre-settlement system for facilitating a securities 
transaction and comprising: 

a. a computer processing mechanism; 

b. an interfacing mechanism adapted for interfacing the computer 

5 processing mechanism with at least two of the following entities: a seller of a 
securities instrument, a buyer of the securities instrument, and a holder of the 
securities instrument; 
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wherein, in response to the issuance of a notification of execution 
(NOE) message from the interfacing mechanism, the computer provides 
10 multilateral data communications between the at least two entities. 

22. The post- trade, pre-settlement system of claim 21 wherein the 
multilateral data communications includes data specifying at least one of a 
settlement location or venue; a source allocation for the securities transaction; 
and an amount of net proceeds for the securities transaction. 

23, The post-trade, pre-settlement system of claim 2 1 wherein, for a 
first securities transaction, data specifying at least one of: 

(a) a first proposed settlement location, 

(b) a first proposed source allocation, and 

5 (c) a first proposed amount of net proceeds, 

are entered into the interfacing mechanism, and, for the first securities 
transaction, data specifying at least one of: 

(d) a second proposed settlement location, 

(e) a second proposed source allocation, and 
10 (f) a second proposed amount of net proceeds, 

are entered into the interfacing mechanism; 
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the computer processing mechanism further including a matching 
mechanism for identifying any matches between the first and second proposed 
settlement locations, the first and second proposed source allocations, and the 
15 first and second proposed amounts of net proceeds. 



24. The post-trade, pre-settlement system of claim 21 wherein the 
computer further includes a confirmation mechanism for sending a 
confirmation message to the interfacing mechanism, the confirmation message 
identifying matches, if any, between the first and second proposed settlement 
5 ' locations, the first and second proposed source allocations, and the first and 
second proposed amounts of net proceeds. 



25. The post-trade, pre-settlement system of claim 24 wherein the 
interfacing mechanism includes at least a first interface situated within a first 
region defined with reference to geographic, economic, and/or political 
boundaries, and a second interface not situated within the first region, so as to 
5 facilitate a cross-border securities transaction. 
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26. The post-trade, pre-settlement system of claim 24 wherein, for a 
first securities transaction, a first data set specifying at least one of: 

(a) a first proposed settlement location, 

(b) a first proposed source allocation, and 

5 (c) a first proposed amount of net proceeds, 

are entered into the interfacing mechanism, and, for the first securities 
transaction, a second data set specifying at least one of: 

(d) a second proposed settlement location, 

(e) a second proposed source allocation, and 
10 (f) a second proposed amount of net proceeds, 

are entered into the interfacing mechanism; and 

for a second securities transaction, a third data set specifying at least one 

of: 

(a) a first proposed settlement location, 
15 (b) a first proposed source allocation, and 

(c) a first proposed amount of net proceeds, 
are entered into the interfacing mechanism; and 

for the second securities transaction, a fourth data set specifying at least 

one of: 

20 (d) a second proposed settlement location, 

(e) a second proposed source allocation, and 
. (f) a second proposed amount of net proceeds, 
are entered into the interfacing mechanism; 
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the computer processing mechanism further including a matching 
25 mechanism for matching the first data set to the second data set, for matching 
the third data set to the fourth data set, and for identifying any matches, as 
between the first and second data sets, for the first and second proposed 
settlement locations, the first and second proposed source allocations, and the 
first and second proposed amounts of net proceeds. 



27. A method for facilitating settlement of a securities transaction 
including the steps ofi 

(a) receiving transaction parameter messages setting forth one or more 
parameter values related to a securities transaction; 
5 (b) a determining matches between one or more parameter values of any 

two or more transaction parameter messages; and 

(c) transmitting an indication message specifying at least one of: (i) the 
existence of matches between one or more parameter values of any two or 
more transaction parameter messages; and (ii) the non-existence of matches 
10 between one or more parameter values of any two or more transaction 
parameter messages. 

28. The method of claim 27 wherein one or more respective parameter values 
are associated with corresponding tolerances setting forth a maximum 
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acceptable deviation for the respective parameter value, 

and wherein the method further includes the step of identifying matches 
5 between parameter values within the maximum acceptable deviation. 



29. The method of claim 27 further including the steps of: 

(a) accepting incoming transaction parameter messages related to a first 

securities transaction and incoming transaction parameter messages related to a 

second securities transaction; 
5 (b) distinguishing incoming transaction parameter messages related to 

the first securities transaction from incoming transaction parameter messages 

related to the second securities transaction; 

(c) determining compatibility between two or more incoming transaction 

parameter messages related to the first securities transaction; and 
10 (d) determining compatibility between two or more incoming 

transaction parameter messages related to the second securities transaction. 

30. The method of claim 27 wherein the transaction parameter 
messages include parameter values specifying at least one of a settlement 
location or venue; a source allocation for the securities transaction; and an 
amount of net proceeds for the securities transaction. 
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31. The method of claim 27 wherein the incoming transaction 
parameter messages include parameter values specifying at least one of: 

(a) a first proposed settlement location, 

(b) a first proposed source allocation, and 

5 (c) a first proposed amount of net proceeds, 

and parameter values specifying at least one of: 

(d) a second proposed settlement location, 

(e) a second proposed source allocation, and 

(f) a second proposed amount of net proceeds, 
10 the method further including the step of: 

determining transaction parameter message compatibility by identifying any 
matches between the first and second proposed settlement locations, the first 
and second proposed source allocations, and the first and second proposed 
amounts of net proceeds. 

15 

32. A method for facilitating settlement of a cross-border securities 
transaction between a first party and a second party, the first party being a 
seller or a seller's representative and the second party being a buyer or a buyer's 
representative, the transaction being defined by a plurality of parameters, the 
5 method including the steps of: 

(a) receiving a message from the seller or the seller's representative and 
a message from the buyer or the buyer's representative, said messages each 
setting forth at least one value for at least one parameter relating to the 
transaction; 
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10 (b) storing the received messages; 

(c) comparing the parameter values of the received messages for each of 
a plurality of parameters to identify at least one of compatible and incompatible 
parameter values; and 

(d) providing an output message indicative of at least one of: (i) 
15 identification of compatible parameter values; and (ii) identification of 

incompatible parameter values* 

33. The method of claim 32, wherein a parameter comprises a value and a 
tolerance for the value. 

34. The method of claim 33 further including the step of determining 
whether a parameter received from the first party is within the tolerance for the 
value received from the second party. 

35. The method of claim 32, wherein a parameter has a default value. 

36. The method of claim 32, wherein a parameter has a default 
tolerance. 

37. The method of claim 32, wherein a parameter identifies the seller 
or the seller's representative and the buyer or the buyer's representative* 

38. The method of claim 32, further including the step of assigning a 
unique identifier to a particular transaction* 

3 9. The method of claim 32, further including the step of utilizing a 
transaction parameter to identify a custodian for the seller's security. 
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40. The method of claim 39, further including the step of utilizing a 
transaction parameter to identify a custodian for receipt of the buyer's security. 



41 . The method of claim 39, further including the step of notifying 
the custodian for the seller's security and the custodian for receipt of the buyer's 
security of a consummated transaction. 

42. A method for facilitating settlement of a cross-border securities 
transaction between a seller's representative and a buyer's representative, the 
securities transaction being defined by a plurality of parameters, the security 
being held by a custodian, the method including the steps of: 

S receiving messages from the seller's representative and the buyer's 

representative, said messages including parameter values for at least one 
parameter relating to the securities transaction; 
storing the parameter values; 

notifying the seller's representative and the buyer's representative of the 
10 parameters pertaining to the securities transaction; and 

providing an indication to at least one of the seller's representative and 

the buyer's representative of one or more parameter values for the securities 

transaction. 
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43. A method for facilitating settlement of a securities transaction 
including the steps of: 

(a) receiving transaction parameter messages setting forth one or more 
parameter values related to a securities transaction; 
5 (b) storing transaction parameter messages; 

(c) determining matches between one or more parameter values of any 
two or more transaction parameter messages related to the securities 
transaction; 

(d) transmitting an indication message over the communications 

10 mechanism, the indication message specifying at least one of: (i) the existence 
of matches between one or more parameter values of the any two or more 
transaction parameter messages; and (ii) the non-existence of matches between 
one or more parameter values of any two or more transaction parameter 
messages. 

44. The method of claim 43 further including the steps of: 

(a) receiving transaction parameter messages related to a first securities 

transaction and transaction parameter messages related to a second securities 

transaction; 

5 (b) distinguishing incoming transaction parameter messages related to 

the first securities transaction from incoming transaction parameter messages 
related to the second securities transaction; and 
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(c) determining compatibility between two or more incoming transaction 
parameter messages related to the first securities transaction. 



45. The method of claim 44 further including the step of determining 
compatibility between two or more incoming transaction parameter messages 
related to the second securities transaction. 

46. The method of claim 43 further including the steps of: 

(a) receiving incoming transaction parameter messages related to a first 
securities transaction and specifying at least one of: 

(a) a first proposed settlement location, 
5 (b) a first proposed source allocation, and 

(c) a first proposed amount of net proceeds, 

(b) receiving incoming transaction parameter messages related to the 
first securities transaction and specifying at least one of: 

(d) a second proposed settlement location, 
10 (e) a second proposed source allocation, and 

(f) a second proposed amount of net proceeds, 

(c) determining compatibility by identifying any matches between the 
first and second proposed settlement locations, the first and second proposed 
source allocations, and the first and second proposed amounts of net proceeds. 
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47. A post-trade, pre-settlement method for facilitating a securities 
transaction, the method for use with a system comprising: a computer 
processing mechanism and an interfacing mechanism adapted for interfacing 
the computer processing mechanism with at least two of the following entities: 
5 a seller of a securities instrument, a buyer of the securities instrument, and a 
holder of the securities instrument; the method comprising the steps of: 

(a) the interfacing mechanism receiving at least one of a notification of 
execution (NOE) message and/or a block order notification (BON) message; 
and 

10 (b) in response to receipt of the NOE and/or BON message from the 

interfacing mechanism, the computer providing multilateral data 
communications between the at least two entities. 



48. The post-trade, pre-settlement method of claim 47 wherein the 
multilateral data communications includes data specifying at least one of a 
settlement location or venue; a source allocation for the securities transaction; 
and an amount of net proceeds for the securities transaction. 

49. The post r trade, pre-settlement method of claim 47 wherein, for a first 
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securities transaction, data specifying at least one of: 

(a) a first proposed settlement location, 

(b) a first proposed source allocation, and 

5 (c) a first proposed amount of net proceeds, 

are entered into the interfacing mechanism, and, for the first securities 
transaction, data specifying at least one of: 

(d) a second proposed settlement location, 

(e) a second proposed source allocation, and 
10 (0 a second proposed amount of net proceeds, 

are entered into the interfacing mechanism; 

the computer processing mechanism further including a matching 
mechanism for identifying any matches between the first and second proposed 
settlement locations, the first and second proposed source allocations, and the 
15 first and second proposed amounts of net proceeds. 



50. The post-trade, pre-settlement method of claim 47 further including 
the step of the computer sending a confirmation message to the interfacing 
mechanism, the confirmation message identifying matches, if any, between the 
first and second proposed settlement locations, the first and second proposed 
5 source allocations, and the first and second proposed amounts of net proceeds. 
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51 • The post-trade, pre-settlement method of claim 50 wherein the 
interfacing mechanism includes at least a first interface situated within a first 
region defined with reference to geographic, economic, and/or political 
boundaries, and a second interface not situated within the first region, so as to 
5 facilitate a cross-border securities transaction. 



52. The post-trade, pre-settlement method of claim 50 further including 
the steps of: 

(a) for a first securities transaction, entering a first data set specifying at 
least one of: 

5 (i) a first proposed settlement location, 

(ii) a first proposed source allocation, and 

(iii) a first proposed amount of net proceeds, 
into the interfacing mechanism, 

(b) for the first securities transaction, entering a second data set 
10 specifying at least one of: 

(iv) a second proposed settlement location, 

(v) a second proposed source allocation, and 

(vi) a second proposed amount of net proceeds, 
are entered into the interfacing mechanism; 
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15 



(c) for a second securities transaction, entering a third data set 



specifying at least one of: 



(i) a first proposed settlement location, 



(ii) a first proposed source allocation, and 



(iii) a first proposed amount of net proceeds, 



20 into the interfacing mechanism; 

(d) for the second securities transaction, entering a fourth data set 
specifying at least one of: 



into the interfacing mechanism; and 

(e) matching the first data set to the second data set, matching the third 
data set to the fourth data set, and for identifying any matches, as between the 
first and second data sets, for the first and second proposed settlement 
30 locations, the first and second proposed source allocations, and the first and 
second proposed amounts of net proceeds. 

S3. A method of facilitating settlement of a securities transaction for 
use with a system that is adapted to receive, store, and determine matches 
between two or more transaction parameter messages each specifying one or 



(iv) a second proposed settlement location, 



(v) a second proposed source allocation, and 



25 



(vi) a second proposed amount of net proceeds, 
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more transaction parameter values related to the securities transaction, the 
5 method including the steps of: 

(a) inputting data setting forth one or more parameter values related to 
the securities transaction; the data comprising a transaction parameter message; 

(b) receiving an indication message specifying at least one of: (i) the 
existence of matches between one or more parameter values of the any two or 

10 more transaction parameter messages related to the securities transaction; and 
(ii) the non-existence of matches between one or more parameter values of any 
two or more transaction parameter messages related to the securities 
transaction. 



54. The inethod of claim 53 wherein the system is further adapted to 
distinguish incoming transaction parameter messages related to a first securities 
transaction from incoming transaction parameter messages related to a second 
securities transaction, and for determining compatibility between two or more 
5 incoming transaction parameter messages related to the first securities 
transaction; the method further including the step of: 

inputting transaction parameter messages related to the first securities 
transaction and transaction parameter messages related to the second securities 
transaction. 
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55. The method of claim 54 wherein the system is further adapted to 
determine compatibility between two or more incoming transaction parameter 
messages related to the second securities transaction. 

5 

56. The method of claim 53 further including the steps of: 

(a) inputting incoming transaction parameter messages related to a first 
securities transaction and specifying at least one of: 

(a) a first proposed settlement location, 
5 (b) a first proposed source allocation, and 

(c) a first proposed amount of net proceeds, 

(b) inputting incoming transaction parameter messages related to the 
first securities transaction and specifying at least one of: 

(d) a second proposed settlement location, 
10 (e) a second proposed source allocation, and 

(f) a second proposed amount of net proceeds, 
the system determining compatibility by identifying any matches between the 
first and second proposed settlement locations, the first and second proposed 
source allocations, and the first and second proposed amounts of net proceeds. 
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57, A post-trade, pre-settlement method for facilitating a securities transaction, 
the method for use with a system comprising: a computer processing 
mechanism and an interfacing mechanism adapted for interfacing the computer 
processing mechanism with at least two of the following entities: a seller of a 
securities instrument, a buyer of the securities instrument, and a holder of the 
securities instrument; the method comprising the steps of: 

(a) inputting into the interfacing mechanism at least one of a notification 
of execution (NOE) message and/or a block order notification (BON) message; 

and 

(b) in response to receipt of the NOE and/or BON message from the 
interfacing mechanism, the computer providing multilateral data 
communications between the at least two entities. 

58. The post-trade, prc-settlement method of claim 57 wherein the 
multilateral data communications includes data specifying at least one of a 
settlement location or venue; a source allocation for the securities transaction; 
and an amount of net proceeds for the securities transaction. 

59. The post-trade, pre-settlement method of claim 57 wherein, for a 
first securities transaction, entering d?ta specifying at least one of: 

(a) a first proposed settlement location, 
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(b) a first proposed source allocation, and 
5 (c) a first proposed amount of net proceeds, 

into the interfacing mechanism, and, for the first securities transaction, entering 
data specifying at least one of: 

(d) a second proposed settlement location, 

(e) a second proposed source allocation, and 
10 (f) a second proposed amount of net proceeds, 

into the interfacing mechanism; 

receiving a notification from the computer processing mechanism that 
identifies any matches between the first and second proposed settlement 
locations, the first and second proposed source allocations, and the first and 
15 second proposed amounts of net proceeds. 

60. The post-trade, pre-scttlement method of claim 57 further including 
the step of receiving a confirmation message at the interfacing mechanism, the 
confirmation message identifying matches, if any, between the first and second 
proposed settlement locations, the first and second proposed source allocations, 

5 and the first and second proposed amounts of net proceeds. 

61. The post-trade, pre-settlement method of claim 60 wherein the 
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interfacing mechanism includes at least a first interface situated within a first 
region defined with reference to geographic, economic, and/or political 
boundaries, and a second interface not situated within the first region, so as to 
5 ' facilitate a cross-border securities transaction. 
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62. The post-trade, pre-settlement method of claim 60 further including 
the steps of: 

(a) for a first securities transaction, entering a first data set specifying at 
least one of: 

5 (i) a first proposed settlement location, 

(ii) a first proposed source allocation, and 

(iii) a first proposed amount of net proceeds, 
into the interfacing mechanism, 

(b) for the first securities transaction, entering a second data set 
10 specifying at least one of: 

(iv) a second proposed settlement location, 

(v) a second proposed source allocation, and 

(vi) a second proposed amount of net proceeds, 
are entered into the interfacing mechanism; 

15 (c) for a second securities transaction, entering a third data set 

specifying at least one of: 

(i) a first proposed settlement location, 

(ii) a first proposed source allocation, and 

(iii) a first proposed amount of net proceeds, 
20 into the interfacing mechanism; 

(d) for the second securities transaction, entering a fourth data set 
specifying at least one of: 
(iv) a second proposed settlement location, 
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(v) a second proposed source allocation, and 

(vi) a second proposed amount of net proceeds, 
into the interfacing mechanism; and 

(e) matching the first data set to the second data set, matching the third data set to 
5 the fourth data set, and for identifying any matches, as between the first and second data 
sets, for the first and second proposed settlement locations, the first and second proposed 
source allocations, and the first and second proposed amounts of net proceeds. 

63. A system for facilitating settlement of a securities transaction between a buyer 
and a seller, comprising: 

(a) a communications mechanism for transmitting and receiving messages from 

the buyer and the seller, the messages including one or more parameter 
values related to the transaction; 

(b) a processing mechanism, coupled to the communications mechanism, 

(i) for determining the compatibility of parameter values received in 

messages from the buyer and seller, and 

(ii) for transmitting, via the communications mechanism, to at least one of 

the buyer and the sell, the compatibility determination in part (i); 
wherein at least one of said messages is transmitted across geographic, economic, and/or 
political boundaries. 

64. The system of claim 63, wherein the processing mechanism further comprises 
translating a security identification into a different type of security identification. 
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65. The system of claim 64, wherein the processing mechanism translates CUSII 
into ISIN. 

66. The system of claim 64, wherein the processing mechanism translates ISIN 
into CUSIP. 

67. The system of claim 63, further comprising an interfacing mechanism adaptec 
for interfacing the processing mechanism with at least two of the following six entities: 
a seller of a securities instrument, a representative of the seller of a securities instrument, 
a buyer of the securities instrument, a representative of the buyer of a securities 

5 instrument, a holder of the physical securities instrument, and a recipient of the physical 
securities instrument 

68. The system of claim 67, wherein the at least two entities are located in 
different geographic, economic, and/or political locations. 

69. The system of claim 68, wherein at least one of the at least two entities is the 
seller or the buyer, 

70. The system of claim 68, wherein at least one of the at least two entities is a 
representative of the seller or a representative of the buyer. 

71 . The system of claim 68, wherein at least one of the at least two entities is the 
holder of the physical securities instrument or the recipient of the physical securities 
instrument. 

72. The system of claim 63, wherein said communications mechanism or said 
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73. The system of claim 72, wherein the seller, the buyer, and the 
processing mechanism are in three different international geographic, 
economic, and/or political locations. 
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74. The system of claim 72, wherein the representative of the seller, the 
representative of the buyer, and the processing mechanism are in three different 
international geographic, economic, and/or political locations. 
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Description 


ABS 


Asset Backed Securities 


ANNA 


Association of National Numberina Agencies 


B/O 


Broker/Dealer _ 


B1C 


Bank Identifier Code 


BON 


Block Order Notification 


cso 


{"antral Securitira Deoositorv 


CUSIP 


Committee on Security Identification Procedures 


n\c 


Pont Know — 


P5P 




DVP 


Delivery Versus Payment — 


FOP 


Free of Payment 


FIX 


Financial Information Exchange 




Global Custodian 


GSTPA 


ftinhai Strainht Throuoh Processlno Association 




international Central Securities Depository 


TM 


Investment Manaqer 


t*tn 


international Securities Identification Number 


ISO 


International Standards Organisation 


MBS 


Mortqaqe Backed Securities 


wnp 


Notice of Execution 


NP 


Net Proceeds 




Partitioant Access Module 


PflM 

RAC 


Reouirements Advisory Council 


RF1 
RFP 


Request for Information — 

Recuest for Proposal — 


SO 


Settlement Details 


SEDOL 
SID 


Stock Exchange Daily Official List 
Standing Instruction Database 


SIS 
SWIFT 


SIS SeoalnterSettle AG J 

Sodety for Worldwide Interbank Financial 
Telecommunication 


TAC 
TBA 


Technical Advisory Council — 

To Be Assiqned Instruments 


TCS 
TFM 
TKS 


Tata Consultancy Services . 

Transaction Flow Manager 

Teknosoft SA . . -1 
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TFM will start with a T. u The TFM will ensure that 
the participant trade reference # Is unique for 
every participant. Recycling of the participant trade 
reference # will depend on the housekeeping period 
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> Revoke Cancel 
* Revoke Reject 

> Dispute. 


Valid Values are: 

► Institutional trade 

> Basket/portfollo/program trade 

Default value Is Institutional trade. 


Valid Values are: 

> Institutional trade 

> Broker-to-Broker trade 

> Fund-to-Fund trade 

> Pre- Allocated Trade. In the case of a Pre- 
Allocated Trade, the B/D will be expected to 
submit the Allocations for the Block Trade. 

Default value is Institutional trade. 


Party Details 


Valid values are: 

> Buy 

> Sell. 

For a buy, the first eight characters of the 
actual sender's BIC should be the same as the first 
8 characters of the buy Indicator BIC, with a 
Buy/Sell Indicator of "BUY." The opposite Is true 
for sell. 


The buyer must be defined as a valid participant In 

the TFM. The buyer must have a role as either an 

"IM-ora *B/D"ln theTFM. 

The role of the buyer must be compatible with the 

processing type used. For example, in processing 

type *BTB* both the buyer and the seller must 

have the role of a broker. 

The Seller must be defined as a valid oarticipant in 
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Indicates the transaction type used by the sender and 
will determine the transaction processing variation. 


Indicates the processing type used by the sender and 
will determine the processing variation. 


Indicates whether the actual sender is acting as a 
buyer or a seller. 


Identifies the Buyer of the trade. 
Identifies the Seller of the trade. 


' .1* . * 
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Trade Transaction 
Type 


Processing Type 


Buy/Sell Indtcator 


Buyer Identification 
Seller Identification 
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lid Values are: 
30/360 Basis 
307365 BasJs 
30/Actual Basis 
Actual/30 Basis 
Actual/360 Basis 
Actual/365 Basis 
Actual/Actual Basis 
Eurobond Basic. 


lid Values are; 




lid Values are: 
Yes 
No. 


lid Values are: 
Ves 
No. 


ilid Values are: 
Yes 
No. 


Valid Values are: 

> Zero 

> OrlQlnal Issue Discount 
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Spedfles the date on which the rate on Floating Rate 
Note will be reset. 

Specifies the conversion date for convertible bonds 


buedfies ihe view at maturity induding Interest, etc. 
Spedfles the numbers of days for which the Interest 
has accrued. 


inoicares now the interest Is to be computed for the 
security. 






apeanes ii trie security can be converted to another 
class of security. 


apeanes u tne interest rate for the security is variable 
or not 


Indicates the coupon types like Zero Interest, Original 
Issue Discount, Adjustable Rate, etc. 
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Dated Date 


Floating Rate Note 
Reset Date 
Conversion Date 
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AH of these fields are used for fixed Income 
Instruments. 
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This field must be specified for asset backed and 
mortgage backed securities. 


This field must be specified for asset backed and 
mortgage backed securities. 


This field must be specified for asset backed and 
martgaae backed securities, 
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Valid Values are; 

> Agency 

> Principal 

> Crossing as principal 

> Crossing as agent 

> Acting as agent for person other than customer 

> Atting as agent for both customer and another 
person 

> Acting as agent for some executions and as 
principal for others In the transaction 

> Risk lfi£S nrinrinal 


1 
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Valid values are: 

> Clean 

> Dirty. 

Default value Is "Clean." 
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tmpncray part or me trade agreement. This field is 
applicable to the NOE only. In most cases, the GC will 
respond with the same location as that of the D/O in 
the settlement details. However, in some cases the GC 
may respond with a different location. In such cases, 
the settlement details match process will try tc 
determine if there is a bridge between the locations. If 
there is no bridge available, the B/D and the GC will 
have to resolve the differences. 


jnoicares wnemer tne WD is acting In its capacity as an 
agent or a principal. Applicable to NOE only. 


Indicates If the trade is a short safe or not. Applicable 
to the NOE only. 


.inmcaies ir tne price includes or excludes commissions. 
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Valid Values are: 
> Cum Bonus 
* Ex Bonus. 


Valid Values are: 

> Cum Dividend 

> Ex Dividend. 


Valid Values are: 

> Sell before ex date without the coupon 

► Buy after ex date with the coupon. 


Valid Values are: 

> Cum rights 

► Ex rights. 


Valid Values are: 

► Cum warrants 

► Ex warrants. 


Valid Values are: 

> Warrants attached 

> Warrants not attached. 


Valid Values are: 
> Solicited 


Valid Values are: 

> Primary market trade 

> Not a primary market trade. 

Default value ls u Not a primary market trade. 0 
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Descripllon 


indicates whether the trade has been executed Cum or 
Ex bonus. 


indicates wnemer tne trade has been executed Cum or 
Ex dividend. 


Indicates wnecner a sell trade before ex date is without 
the coupon and a buy trade after the ex date is with 
the coupon. 


uwitmea wnecner tne trade has been executed Cum or 
Ex rights. 


indicates whether the trade has been executed Cum or 
Ex warrants. 


indicates wnecner tne security has warrants attached or 1 
not. 1 


matcaces whether the trade Is a solicited or an 
unsolicited trade by the B/D. 


indite* If xhe craae is a primary market trade or not. 
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Field Name 1 Remarks i 


Trade Transaction Type and Processing 
Type 


1 This field should match exactly (e.g., an 
institutional trade should match with an 
institutional trade). 




Message Type 


NOE should match with a BON and vice- 
1 versa. In the case of Broker-to-Broker 

trades, the executing broker must give an 
I NOE and the counterpart broker must give a 
I BON. Tn the case of Fund-to-Fund trades, 

the participating IMs will submJt a BON and 

the virtual broker (which could be an IN) 

will submit the NOC. 




Buyer, Seller and Buy/Sell Indicator 


Buyer, Seller and buy/sell indicator are 
matched exactly. 




Security Identification Details 

> Primary Numbering Agency Code 

> Identification in Primary Numbering 
Agency Code 

> Security Identification in the Local 
Market (if specified by both the 
parties) 

> Issue Currency 

> Race of Trade 


| Each security, based on the type of 
instrument and country of issue, will have a 
Primary Numbering Agency Code. The 
match win happen in the security 
Identification In the Prtmary Numbering 
Agency Code. If participants do not supply 
the Security Identification in the Primary 
Numbering Agency Code, the TFM will carry 
out a translation. If the security 
identification is matched on a translated 
code, the TFM will compare the place of 
trade and issue a warning, if they are 
different This will enable participants to 
verify the correctness of the translation of 
dual fisted securities. 




Block Trade Quantity and Original Par 
Value. 


This field will be matched exactly. 


Price | 

> Trade Currency 

> Price 

> Forex Rate ( 

> Settlement Currency | 

> Block Gross Amount J 
External RBferencB 

1 

i 


Participants can indicate in their profiles if 
they need an exact match on price. 
Participants can also specify, if they do not 
need an exact match on price and if they 
need a tolerance match on settlement 
amount, whether they would provide the 
External Reference #s or not. The following 
cases summarise the matching on price 1 
based on profile settings. 
Case 1: Either or both participants need 
an exact match on price. The following 
fields are matched exactly in this case: 

> Trade Currency 

> Price 

> Forex Rate (if specified). 

Case 2: Neither requires an exact match on 
price. Both participants want a tolerance 
match only if they agreed upon external 
reference #s match. The following fields are 
matched exactly m 
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Ffefd Name 


Remarks 


> 


this case: 

> Settlement Currency 

> External Reference # 

The Block Gross Amounts are matched 
within the lowest of the tolerances specified 
by the two participants. 
Case 3: Both participants do not need exact 
match on price. Either or both participants 
also do not need to match on the external 
reference # for a tolerance match on Block 
Gross Amount In this case the Settlement 
Currency is matched exactly and the Block 
Gross Amount is matched within the lowest 
of the tolerances specified by the two 
participants. 


Trade Date 


This field will be matched exactly. 


Settlement Date 


This field will be matched exactly. 


External Reference # 


mis neiu win oe roatcneo exactly, n 
specified by both parties. 


Broker Commission 


Participants can set up profiles to indicate 
whether they require a match on broker 
commissions or not. The cases described for 
price match will also be applicable for the 
Broker Commissions. However, Broker 
Commission win not have a tolerance 
match. 

If both participants have indicated that they 
do not need an exact match on 
commissions, the TFM will issue a warning if 
the commissions are different. 


Method of Settlement 


This field will be matched exactly. 



FIG. 5B 
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IM 



BON FOR 



BUY SIDE 



BON FOR 



SELL SIDE 



TFM 
MATCH TRADE 

MATCH TRADE 



NOE FOR 



BUY SIDE 



NOE FOR 



SELL SIDE 



COMMON 
VIRTUAL 
BD 



BOTH THE BUY AND SELL SIDES OF THE FUND-TO-FUND TRADE WILL HAVE 
A COMMON LINK NUMBER WHICH LINKS BOTH SIDES OF THE TRADE 



FIG. 6 
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ALLOCATIONS COME ALONG WITH BON. OR SEPARATELY, MATCHING THE 
ALLOCATIONS QUANTITY WITH THE BON QUANTITY 



FIG. 7 



INVESTMENT MANAGER 



TFM 



BROKER/DEALER 



BON 



ALLOCATIONS 



J 



MATCH TRADE 

MATCH 
ALLOCATIONS 




BON ARRIVES AFTER THE NOE, WITH OR WITHOUT ALLOCATIONS, 
MATCHING THE ALLOCATIONS QUANTITY WITH THE TRADE QUANTITY 



FIG. 8 
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MESSAGE 1 



MESSAGE 2 



MESSAGE 3 



ALLOCATIONS 
MESSAGE 4 



MESSAGES 



MATCH 
ALLOCATIONS 



ALLOCATIONS COME IN AS PARTIAL ALLOCATIONS IN 5 MESSAGES 
EACH ALLOCATION MESSAGE HAS TWO ALLOCATIONS 

ALLOCATIONS QUANTITIES ARE COMPARED WITH THE UNALLOCATED 

TRADE QUANTITY 



FIG. 9 
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STEP OUT 



MESSAGE 



ALLOCATIONS 



MESSAGE 2 



TFM 
MATCH 
ALLOCATIONS 



MATCH STEP 
OUT TRADE 



STEP OUT 
BROKER 



STEP IN 
BROKER 



Z7 



*1 NOTIFICATION OF STEP OUT TRADE WITH BON AND ALLOCATION PARTICULARS WITH 
NEW TRADE REFERENCE NUMBER 

*2 NOTIFICATION OF STEP OUT TRADE FOR BROKER-TO-BROKER LEG DEPENDING ON 
PROFILE OF STEP OUT BROKER 

*3 NOE AND NET PROCEEDS FROM STEP IN BROKER IN RESPONSE TO MESSAGE 1 TFM 
PERFORMS MATCH WITH MESSAGE 1 

*4 NOE AND NET PROCEEDS FROM STEP IN BROKER IN RESPONSE TO MESSAGE *2. TFM 
PERFORMS MATCH WITH MESSAGE *2 



FIG. 12 
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WITH GC PARTICULARS 

BD CAN ALSO PROVIDE 
COMPLETED ALLOCATIONS 



FIG. 13 
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ALLOCATIONS 



FOR BUY SIDE 
ALLOCATIONS 



FOR SELL SIDE 



TFM 

WATCH 
ALLOCATIONS 

MATCH 
ALLOCATIONS 
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ALLOCATION 



NOTIFICATIONS 



COMMON VIRTUAL 
BROKER 

(IM AGENT) 



FIG. 15 



SUBSTITUTE SHEET (RULE 26) 



WO 03/065256 



37/135 



| 

fi 
6; 




The sender must be a valid and active participant in 
the TFM. This field will be sent as part of the 
message header information. 


This field must be specified if the physical sender is 
different from the actual sender of the message. 


ol Fields 1 


* 






f* 

On 
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1 Reference Data, Trade Identincatlon and Contr. 
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0 




•'»■ t . 
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Identifies the physical sender of the message to the 
TFM, Normally the physical sender of the message will 
be the same as the actual sender of the message. If 
participants are using a concentrator, the party sending 
the message will be concentrator. The actual sender of 
the message will be the participant who Is submitting 
the message through the concentrator. 


Identifies the actual sender of the message. This field 
will be specified If the physical sender of the message Is 
different from the actual sender of the message. 
Otherwise, the actual sender will be assumed to be the 
same as the physical sender. 


Identifies the actual sender of the trade. If the 
substituting party is providing the net proceeds details, 
the actual sender identification of the trade will be the 
IM or the B/O. Otherwise this will be the same as the 
actual sender identification of the message. 


Identifies the physical sender through which the 
participant has sent the trade, if the participant wants 
to use the physical sender as a part of the identification 
of its trade. 


The unique reference 4 for every trade sent to the TFM 
by each participant. Participants use this sender's 
reference number to identify trades uniquely in the 
TFM. 


% 

3, 


Sender Details 1 


Physical Sender 
Identification 


Actual Sender 
Identification 


Actual Sender 
Identincatlon of the 
Trade 
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Currency Code 


Valid ISO Standard Currency Code 


Currency Name 


Name of the Currency 


Smallest Denomination 


Smallest Denomination. The smallest 
denomination will be used by the TFM as the 
toterance value to validate the gross proceeds for 
each allocation. 


FIG. 49 


Country Code 


Valid ISO Country Code 


Country Name 




Currencies supported 


Indicates the Nst of currency in use In the 
country. 


Default Settlement Location 


This will be maintained by instrument type. 



FIG, g o 



Instrument Typt 


ISTTC standards for instrument tvoes. 


Country Code 


ISO Country Codes. 


Primary Numbering Agency Code 


Valid Values are : 




> I5IN 




> OS for CUSIP 




> GB for SEOOL 




> JP for OUIK. 
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Settlement Location 


Identification of the Settlement Location 


Name 


Institution Name 


Currencies of Settlement 


Settlement Currencies supported at the 
Location 


Default Settlement Currency 


The default Settlement Currency 


Country 


Country of Settlement Location 


Settlement Calendar 


Valid settlement dates at the Location 


TFM Deadlines 


Generic deadlines to be followed in the 
TFM for Net Proceeds match and 
Settlement match 


Method of settlement supported 


Types of transactions supported in the 
Settlement Location (i.e., Book entry, 

DVP/RVP. DFP/RFP. FOP> 


Market Tolerance for Net Proceeds Match 


Absolute value for the respective currency 
and Instrument type 


Instrument type 


Categories of Securities supported (i.e., 
EouitY, Fixed Income, etc.) 



FTG.S2 
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Settlement Location Identification 


Unique identification of the Settlement 
Location 


Bridge Location 


This identifies the Settlement Location 
which has a Bridge Link with the above 
Settlement Location 


Currencies of Settlement 


Currencies supported by the Bridqe 


Instrument Type 


Categories of Securities supported (i.e., 
Equity, Fixed Income! etc) 


Method of Settlement Supported 


Method of settlement supported at the 
bridge for the Settlement Location (i.e., 
Book entry - DVP/RVP r DFP/RFP, FOP). 


Sub-custodiaiVIdentificatfon at the Bridoe 


Sub-custodian/Identfflcation at the Bridoe 


Security Agent Identification 


Security Agent at the Settlement Location 


Security Account at the Location 


Security account at the agent 


Cash Agent Identification 


Cash Agent at the Settlement Location for 
the Bridge 


Cash Account at the Location 


Cash account at the agent 


Transaction Type Codes 


Transaction code used at the Settlement 
Location to identify the Brfdqe 
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Bank Code 


[4 upper case alphabetic characters] 

The Bank Code is unique to each financial institution and identifies the 
Institution worJd-wlde 


Country Code 


[2 upper case alphabetic characters] 

The Country code identifies the country or geographical territory in 
which the user is physically located. The country code must reflect the 
geographical location of the business unit. The country code consists 
of the ISO two character country code fe,q., CH is Switzerland). 


Location Code 


[2 upper case alphanumeric characters] 
The Location Code identifies, within a country or geographical 
territory, the region and/or city in which the business unit is located. 
The location code consists of two components, a region code and a 
suffix code. The region code is a one digit alphanumeric character 
where the digits l 0 l and T are not permitted. The region code may be 
used to: 

• split a country Into geographical parts 

• identify major commercial locations within a country 
or 

• represent a time zone in a country 

The suffix code is a one digit alphanumeric code where the digit '0 1 is 
specially reserved and the letter '0' is not permitted. The following 
rules apply to the suffix code: 

• where required, it enables a subdivision within a region or city 

• the digit T indicates a Non~S.W.I.F.T. BIC 

• the'digit '0* Indicates a test and training destination 


Branch Code 


[3 upper case alphanumeric characters] 

rhe three-character code is an optional component for all BICs. 

[t can be registered to identify: 

• a 100% owned branch of the requesting institution in the 
same country 

• a department/ functional role within the requesting institution 
XXX* is the default branch code for S.W.I.F.T. BICs 
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Role 


Possible Profiles "] 


S/D 


• Notice of pending Transactions (Pending NOE, NP, SD) ~ 

• Kouung 

• Matching Tolerance for block gross amount net proceeds 

• Use of External Common reference number match for j 
applying tolerance on gross amount match. 

• Match on brokerage commission profiles 

• Settlement Deadlines - Security and Cash (NP match, 
Settlement channel match) 

• Supported transaction types (i.e.. Broker-to-Broker 1 
trades) I 

• Substitution (NP, SD) j 

• SuDDorted settlement bridges j 




IM 


• Notice of pending Transactions (Pending BON, NP) 1 

• Routing | 

• MatChiflO TolSrantl* for* bforW nm« Amnnnf rtat nmriifirtr 1 

• Use of External Common reference number match for 
applying tolerance on gross amount match ( 

■ Match on brokerage commission Profile 

• Client Details (Accounting Agents) 

• Substitution (NP) J 


GC 


• Routing j 

• Settlement Deadlines - securities and cash (NP match, 
>eiuemeriL cnannei matcn) I 

• Substitution (SD) j 

• SuDDorted Settlement Bridqes 1 


Substituting Party ! 


• Will maintain profiles on behalf of the party for whom it is 
substituting. 

• The type of profiles maintained by the substituting party 
will depend on the type of substitution. For example: The 
substituting party for settlement details will maintain the 
profile of the GC for whom it is replacing like deadlines, 
etc. 


Accounting Agent 


• Deadlines for each class of accounts or account | 
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Participant Identification 


Identification of the Participant in the 8- or 11- 
character BIC formats. The matching of the trade 
information will be at the level of 8 characters 
regardless of whether an 8- or 11-character BIC is 
used. 


Name of the Financial Institution 


Name of the Financial Institution that the BIC 
represents 


Additional Name 1 


Additional name, if any 
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Participant Identification 


1 8IC of the Participant 


Address Type 


Type of the address specified. Participants can 
have multiple .addresses for different functional 

ucpafuTiCi IL3 anu wuniaui ucLdifa. i nc Futiuwinp 

information is maintained for each address type. 


Piece _ 


Name of the place 


Internal Address 


Internal Address, if any 


Street Address 


Street Address 


Poft Box Number 


Post Box Number 


Postal Code 


Postal Code 


Country I 


Name of the Country 


Default Address 


Whether this is the default address or not. 
Specified as a Y/N flag 


Contact Person or People 


Name of the Contact Person or People 


Telephone Number 


Telephone Number of the contact person 


Telex 


Telex Number 


Fax Number 


Fax Number 


Email Address 


Email Address of the contact person 1 
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Participant Roles 



IM 


IM 


B/D 


B/D 


GC 


GC 


Interested Party 


An entity, other than the primary participants, which 
might receive information from the TFM at various 
stages of the trade processing* An Interested party 
could be any of the following: 

• Accounting Agent 

■ Lending Agent 

» Trustee, etc 


Substituting Party 


An entity which submits trade Information on behalf of 
a Participant; (e.g., Net proceeds for a B/D or an IM; 
Settlement Details for a GC or a B/D, etc.) 


Reference Data Provider 


Provides reference data such . as BIC, Security 
identification codes and Account numbers 
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PAM Identification 


A Character PAM identification 


Current Message Version 


XML message version supported by the PAM 


Concentrator PAM (Y,N) 


Whether the PAM is a concentrator PAM or 
not 


Owner of PAM 


The BIC to which the PAM is connected 


Swift ON Address 


Distinguished Name Address - SWIFT 
network address for the PAM 


PAM Version 


Version of the PAM software 


PAM Credit 


Credit value for the PAM far inbound 
messages. This is a communication fevei 
field that indicates the number of messages 
the TFM can send to the PAM before 
receiving any acknowledgement from the 
PAM. This is a PAM set up parameter that 
ensures the PAM is not flooded with 
messages from the TFM. 
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RELATIONSHIPS BETWEEN PARTICIPANT. ROLE. BtC PAM TFM AND CONCENTRATOR 



CONCENTRATOR 



^ 












ROLE 


V- 


PARTICIPATE 




BIC 






(LEGAL ENTITY) 









4 



TFM 



PAM 
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Transaction 


Whether Required 
(Options) 


When required 
fOptlons) 


Alleged NOE 


• Yes 

• No 


• Immediately when a trade is 
alleged 

• Periodically (e.g., intervals of 30 
minutes, 60 minutes and so on). 
The Interval specified by the 
participant must be less than the 
TFM specified maximum Interval. 


Alleged BON 


♦ Yes 

• No 


• Immediately when a trade is 
alleged 

• Periodically (e.g.. Intervals of 30 
minutes, 60 minutes and so on). 
The interval specified by the 
participant must be less than the 
TFM soedfled maximum interval. 


Pending Net 
Proceeds 


• Yes 

• No 


• Immediately when the 
counterpart message is received 


Pending 
Settlement 
Details to BO. 
This profile can be 
set up for each 
settlement 
location. 


• Yes 

• NO. 


• Immediately when the settlement 
details from GC is received- 
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Participant 


Identification of the IM or the B/D who has 
specified a substitute for Net Proceeds. 


Substitution type 


Message for which the substitution ID is 
defined - in this case Net Proceeds, 


Substitute Identification 


Identification of the substitute expects to 
submit Net Proceeds. 


Effective Date 


Trade date from which the substitution is 
active. 



FIG. 63 



Participant 


Identification of the GC or B/D who is 
substituted for Settlement Details. 


Substitution Type 


Message for which the substitution ID is 
defined - In this case. Settlement Details. 


IM identification 


Identification of the IM, if the substitution 
is maintained only for a specific IM. 


Substitute Identification 


Identification of substitute who submits 
Settlement Details. 


Effective Date 


Trade date from when the substitution is 
active. 
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IM 


Identification of the FM. 


Class of Account 


Identifies the Class of Account (e.g.. 
Mutual Fund registered In UK, etc.) for 
which the Accounting Aqent is Identified. 


IM Client Account Number or GSTPA Client 
Account Number 


Identifies the Client for which the profiles 
are set up. IMs can set up Accounting 
Agents for a class of account or for a 
specific account If the IM specifies an 
Accounting Agent for a class of account, 
then at each allocation the IM can specify 
the class of account TFM will Identify the 
Accounting Agent to be used based on 
the profile and the Allocation details. 


Accounting Agents 


Identifies the Accounting Agents to whom 
the reporting is done. 


Soft Reporting Indicator 


Indicates whether soft reporting can be 
done to the Accountina Aaent or not 


Indicator to use the B^Ds or IMs net 
orcceeds details for soft reporting. 





FIG. & 


Accountinq Aqent 


Identification of the Accounting Agent. 


Class of Account 


Identifies the Class of Account (e.g., 
Mutual Fund registered in UK, etc.) 


IM 


Identifies the IM for whose clients the 
deadlines are set up. 


IM Client Account Number or GSTPA Client 
Account Number 


Identifies the Client of the IM for which 
the deadlines are set up. 


Reporting Basis 


Indicates whether the reporting has to be 
done based on trade time or Allocation 
Time ■ 


Reporting Method 


Indicates whether the Reporting is based 
on duration or the number of hours 
elapsed after the trade time or the 
allocation time. 


Reporting Type 


Indicates the reporting type (e.g., once a 
day, twice a day, *n" times a day, once a 
week and once a month for duration- 
based reporting and the number of hours 
for elapsed-time reportinq. 


Reporting Deadline (Only applicable for 
duration based reporting) 


Along with the deadline type, the TFM will 

also maintain the deadline time. The 

following is the way in which it will 

maintain the deadline Times: 

Once a Day 

At time of Day. 

"N" times a day 

At *rr times of the Day. 

Once a week 

At day and time of the week. 

Once a month 

At day and time of the month. 


Reporting Period Duration 


Duration will be from date (-N Days) and 
time and to Date and Time (-M Days) and 
Time. The TFM will convert the duration 
to the GMT equivalent based on the time 
zone of the Accountinq Agent. 
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Exact Price Match Indicator 


Indicates whether exact price match on 
the Block Is required or not. 


External Reference Match Indicator 


Indicates whether the external reference 
match is required for tolerance match on 
block qross amount or not. 


Settlement Currency 


Identifies the Settlement Currency for 
which the block tolerance is set up. 


Instrument Type 


Identifies the Instrument Type for which 
the block tolerance is set up. 


Tolerance Amount 


Indicates the Tolerance Amount to be 
used for the Wock aross amount. 
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No. 
Of 

trades 


%Of 
total No. 


Amount 


% of total 
amount 


Submitted trades 










Completed trades 










Cancelled 
trades by 
participant 


Unmatched trade 










After Trade Match 










After NP Match 










After SD Match 










Cancelled trades bv TFM 1 









Message Statistics Table 

FKL6S 



Messages 


Total 
number 


New 


Replace 


Oalete/C 
ancei* 


NOE 










BON 










Allocations 










NP 










SO 


1 


! 



* - Cancel is applicable for NOE and BON and that leads to trade cancel 



Matching Efficiency Table 
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events 


Total 


Missing deadlines 


By Duration Like <t Hour, 1 
and 2 hours, etc.. 


Value 


No. 


Value 


J*. 


No, 




Value 


% 


No* 


% 


Block Trade 
Reportinq 






















Block Trade 
Match 






















Allocations 
Completion 






















NP Match 






















SD Match 




















i 



Geographical characteristics of Usage 

„_____^^_ FIG. 70 



Geography 


No. of 
Trades 


<H>of 
Total 


Value of 
Trades 


<* of Total 
Value 


US market 










Europe 
Market, Africa 
and Middle 
East 










Asia Pacific 




1 
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Instrument 
Tvoe 


No. of 
Trades 


% of 
Total 


Value of 
Trades 


<M> of Total 
Value 


Equities 










Rxed Income 










Domestic or Cross-border Usage of Services Table 


Type of 
Service 


No. of 
Trades 


of 
Total 


Value of 
Trades 


% of Total 
VaJue 


Domestic" 










Cross-border 
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' - A domestfc trade is the one where an the participants to the trade are from the same 
country where the security is issued. 



Standards Compliance Table 

FIG. 73 

Statistics on completed trades with respect to securities identification code usage are 
provided. 



Type of Securities 
Identification Code 


No. of 
Trades 


<¥o at 
Total 


ISIN 






SCDOL 






CUSIP 






QUIK 


1 




Others 


1 
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Reference Number Table 



Message 


Mandatary Reference Numbers 


NwC 


Trade Reference 1. Version 1 


BON 


Trade Reference 2, Version I 


Allocations Assuming that 
there are 3 allocations for 
the trade 


Trade Reference 2, Version t 
Allocation Sequence I, Version 1 
Allocation Sequence 2, Version t 
Allocation Sequence 3, Version 1 


Net Proceeds; From im 


Trade Reference 2, Version 1 

AUocatfon Sequence I, Version l, Net Proceeds Version l 
Allocation Sequence 2, Version I, Net Proceeds Version 1 
Allocation Sequence 3, Version 1. Net Proceeds Version 1 


Net Proceeds: From B/O 


Trade Reference 1, Version a 

Allocation Sequence 1, Version l, Net Proceeds Version l 
Allocation Sequence 2, Version L, Net Proceeds Version 1 
Allocation Sequence 3. Version 1. Net Proceeds Version l 


3eiu«mcnC uetaus. rrgnri 

GC 


1 Trade Reference 2, Version l 

Allocation Sequence I. Version 1, Net Proceeds Version l 

{optional). Settlement Details Version 1 

Allocation Sequence 2, Version 1, Net Proceeds Version 1 

(optKxial),5ettlement Details Version l 

Allocation Sequence 3 f Version X, Net Proceeds Version i 

(optional), Setdement Details Version l 


Settlement Details: From 
B/D 


Trade tl&f6r&nc& 1 Version l 

Allocation Sequence 1, Version l r Net Proceeds Version l 

(optional), Settlement Details Version 1 

Allocation Sequence 2, Version 1, Net Proceeds Version 1 

(optional}, Settlement Details Version l 

Allocation Sequence 3, Version 1, Net Proceeds Version 1 

fODtional). Settlement Details Version l 


Settlement Release 
Instruction: from GC 


Trade Reference 2, Version 1 

Allocation Sequence 1, Version l, Net Proceeds Version 1, 
Settlement Details Version 1, Settlement Release Version 1 
Allocation Sequence 2, Version l, Net Proceeds Version I, 
Settlement OetaUs Version l, Settlement Release Version t 
Allocation Sequence 3, Version I, Net Proceeds Version 
^Settlement Details version l. Settlement Release Version l 
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Messages States In TFM Table 



Message Status 


Description 


Active 


Message is valid for format and business 
reference data verification and is the 
current active message for the trade. 


In Error 


Message has failed validation 


Inactive 


Message was either replaced or deleted by 
another message 


Pending Processing 


Message is waiting for the arrival of another 
message (e.g., Net Proceeds waiting for 
Allocations} 


Overridden 


A lower version of the message arrives after 
the TFM has accepted a higher version. 
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Function of trie ! Description 


n£Wm ! New Messace ' 




t Reolace Messaqe 


CANC 


Cancel Message; On NOE or SON, it amounts to Cancel Trade; On an 
1 other messaaes. it amounts to Delete 


REJM 


Reject of Unmatched NOE or BON alleqed aqainst a Dartidoant 


REVC 


Revoke either Cancel of Trade which is pending approval or a reject 
of an unmatched NOE or BON 


OSPT 


Disputes an Alleged NOE or SON by Indicating a reference * to a 
SON or NOE that should match aaainst the Alleged trade. 



Output Messages from the TFM 

FIG. 76 





Message Types 


Profile 
Driven 

fYM) 


error and Warning Messages 

Acceptance Error and Warning 
Match Error and Wamino 


N 


Acceptance Message 

NOfcVBON, Allocations, Net 
Proceeds, Settlement Oetails 


r 


I Pending Processing Message I Y 
Allocations. Net Proceeds and Setaement Details 1 


Discard Pending Processing Messages j Y 
Allocations, Net Proceeds and Settlement Details 


Notice Of Pending Transaction Message 
Slock Trade 
Net Proceeds 


Y 


Matcn Notification 

Match Reference Notification 

Net Proceeds | 
Settlement Details 1 


N 




Notification j 

Allocation Details to GC before 

trade match 

Allocation Details to GC 
after trade match 

Accounting Information 

Settlement Instructions to GC, 

B/D 

Allocation Details notification to B/D 


Y 

N 

N 
N 

N I 




Status Intimations 

Cancel/DeJete/fteplace Requested 
Cancelled/Deleted/Replaced 
Fully Allocated Trade 


N 

y 

Y 
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The compos:te Slock Trade State :s a comttnation of the Block Trace Scare and 31ocfc 
Trade Allocation Sub-stare. The composite AJ location State is a combination of ms 
Allocation 5ta:e and NP atece ond SO state. 





^^mm^mmm^m^ ^x 










Unmatched Trade 


An accepted NOE or SON is existing and there is no matching 
trade details (NOE or BOW) from the counterparty in the TFM. 


Matched Trade 


Trade details from the IM and the B/D have matched and a 
match reference number is assigned bv the TFH. 


Paired Trade 


A replace on a matched trad* dees not match with the 
counterparty's trade details* Indicates that a previously 
matchucl trade is now being replaced and should not be 
matched wrtha different trade. 


Matched Trade, 
Cancellation Aeouested 


In Matched Trade status, the cancellation submitted by one 
jartv^needs to be approved by the counteroartv. 


Paired Trade, Cancellation 
Requested 


In Paired Trade status, the cancellation submitted bv one 
party needs to be approved by the counteroartv. 


Cancelled Trade 


Tr« trade is cancelled and no further processing can be done 
on the trade. 


Rejected Trade 


Indicates that the alleged trade has been rejected by the i 
counterparty. The party alleging the trade has the option of 
replacing the trade or canceting it 


1 


Block Trade - 

AllocJtfon Sub-States 








Una Itocated 


No allocations have been received for the trade. 


Partially allocated 


1 Some allocations have been received for the trade. However, 
there Is stIJI some unallocated guanCJty remaining for the 
trade. 


fvlly Allocated 


All allocations nave been completed for the trade and there is 
no unallocated quantity remaining for the trade. 


AN NP matched 


au allocations have been completed for tne trade ano the Net j 
Proceeds for all the allocations have matched. 


AJl SO matched 


Af: allocations have been completed for cne trace ano tne 
Settlement details for all the allocations have m*tche4. 


Completed trade 


All allocations have oeen completed for the trade and the Net 
Proceeds and Settlement details for ail the allocations have 
matched. 






Allocation states 








Allocation Acceocet] 


An allocation has been accepted into the JFM for the trade. 


Allocation Incomplete 


An incomplete allocation has been received from the 
Cnoker/Oeaier for a pre-ellocoted trade and an enrichment of 
the allocation is expected from the IM to complete the 
allocation, _ 


Allocation Deleted 


An allocation has been deleted (soft) from the trade. 






Allocation - Net 








IM: Unmatched NP 

] 


Met proceeds have bean accepted for the allocation from the 
M and the B/D has not submitted the Net proceeds for the 


BO: unmatched NP r 

l 


4et proceeds have been accepted for the allocation from the 
i/D and the IM has not submitted the Net proceeds for the 
Hlocation. 


Matched Net Proceeds 1 h 


Jet Proceeds accented from the IM and the B/o ror tne 
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allocation nave mat:ned exacttv or witnin rolerances. 


Net Proceeds Match Fail 


Net Proceeds accepted from cue IM and the 8/0 for die 
allocation nave not maimed witmn tolerances. 


Paired Net Proceeds 


A replace on a matched Net Proceeds for the allocation does 
not match with counterparty's Net proceeds details. 
Indicates that a previously matched Net Proceeds or the 
matched trade or allocation has now being replaced. 






Allocation - Settlement 
Details Sub-Ststos 








I DO; Unmatched 3D 


Settlement details have accepted far the allocation from the 
&7D and the GC has not submitted the Settlement details for 
the allocation. 


GC: Unmatched SO 


Settlement details have accepted for the allocation from the 
GC and the 8/D has not submitted the Settlement details for 
the allocation. 


Settlement Channel 
Compatible 


Settlement details accepted from the GC and the B/D for the 
allocation have matched. 


Settiamtnt Channel 
Intompatfbfe 


Settlement details accepted from the GC and the B/D for the 
allocation have nor matched. 


Paired SO 


A replace on a matched Settlement details for the allocation 
does not match with the counterparty's Settlement details. 
Indicates that a previously matched Settlement details or the 
matched trade or allocation has now 5eira r-olaced. 



FIG 78A 
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FIG. 82A 
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